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SECTION 6 


GROUND SEGMENT 


Raw digital data, as received from the Landsat spacecraft, cannot generate 
images that meet specifications. Radiometric corrections must be made to 
compensate for aging and for differences in sensitivity among the instrument 
sensors. Geometric corrections must be made to compensate for off-nadir look 
angle, and to calculate spacecraft drift from its prescribed path. 
Corrections must be made for look— angle jitter caused by vibrations induced by 
spacecraft equipment. Annotations must be calculated and added. It is the 
function of the Ground Segment to perform these adjustments to the output 
products. § 

The major components of the Landsat Ground Segment and their functions are 
shown in Figure 6.0-1, and a simplified data flow diagram is shown in Figure 
6.0-2. As initially proposed, the Ground Segment schedule defined a hardware 
and software development effort ending in March 1981. It allowed three months 
for segment integration and systems tests, and three months for readiness 
demonstration and on-the-job training for the operations staff. Prior to a 
scheduled launch date of October 1981 for Landsat-D, each of the facilities - 
Operations Control Center, Data Management System and Landsat Assessment 
System - had its own procurement and development schedule to satisfy the 
overall Ground Segment requirements. 

The Ground Segment is located in Building 28 at Goddard Space Flight Center, 
shown in Photo I. 

Throughout 1979, the Ground Segment schedules were adjusted to reflect 
changing ground hardware delivery commitments without significant impact on 
segment delivery. 

Late in 1979, it was recognized that the processing necessary to correct the 
spacecraft jitter environment would substantially increase the complexity of 
the thematic mapper processing algorithms. This complexity added to the 
difficulty of developing and programming the very high speed data processor 
and other special purpose hardware required for TM processing. Additionally, 
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Figure 6.0-1. Major Components of 
and Their Functions 









DRRTS 



Figure 6.0-2. Simplified Data 


3 



Flow Diagram 






BUILDING 28, HOUSING GROUND SEGMENT 


at this time, NASA was directed to plan the transition of Landsat-D operations 
to NOAA. These two factors led to the decision to separate the MSS and TM 
processing functions, using available hardware designs for the MSS Ground 
Segment and defining a separate development cycle for the TM Ground Segment, 

Consideration of these issues were, in part, responsible for the program 
rebaseline activities that included an examination of the entire Ground 
Segment design and implementation concept. As a result of these activities in 
mid-1980, the image processing design concept was changed substantially and a 
new Ground Segment schedule was prepared. The Ground Segment was partitioned 
to provide separate MSS and TM Image Processing Systems with separate Mission 
Management Facilities and a common Data Receive, Record and Storage System. 
The key features of the revised schedule are outlined below. 

The MSS Ground Segment development activities were physically separated from 
TM and off-the-shelf commercially available hardware was used. The control 
center and the MSS processing and production control development efforts were 
rescheduled to be complete by 30 April 1982 allowing a 90-day operational 
readiness period prior to a July 1982 launch. 

Staffing for MSS operations began in October 1981, with training starting in 
February 1982. An MSS operational readiness period began on 1 May 1982 and 
ended with the launch of Landsat 4 on 16 July 1982. After launch there was a 
90-day calibration period. Performance was demonstrated in October 1982. The 
turnover of the Ground Segment (including the CSF) to NOAA was scheduled for 
31 January 1983 with training of the NOAA operations contractor beginning in 
November 1982. 

A six-month effort to prepare the TM Ground Segment by 31 January 1984 for the 
launch of Landsat 5 in March 1984 was initiated in mid-1983. The effort 
consisted of testing software corrections in the image processing and 
production control systems and software enhancement and hardware additions in 
the control center to accommodate operation of both Landsat 4 and 5. A 90-day 
calibration period followed the launch of Landsat 5 on 1 March 1984. 
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Development of the TM Ground Segment was accelerated with the decision to 
launch Landsat 5. Specified processing capability was achieved by 30 April 
1984 and demonstrated in October 1984. Full operational readiness was 
achieved and demonstrated in August 1984, resulting in the turnover to NOAA on 
August 31, 1984, of the fully operational TM Ground Segment. 

The TM Ground Segment activities were redefined and rescheduled to complete 31 
July 1983, which would mark the beginning of a one-year TM R&D period. August 
1984 would mark the end of the TM R&D period and the beginning of a six month 
operational readiness period culminating with the turnover of a fully 
operational - at specified levels - TM Ground Segment to NOAA on 31 January 
1985. 

Because of the one-year period between the launch of Landsat-D (16 July 1982) 
and the completion of the TM Ground Segment development activities (31 July 
1983), NASA made the decision to develop, separately, a single scene per day 
engineering capability for TM to provide early access and evaluation of TM 
data and TM instrument on-orbit performance immediately after launch of 
Landsat-D. This limited capability was dubbed the “Scrounge” system by NASA 
and did impact the TM Ground Segment design methodology and implementation 
schedule. These impacts are discussed later in the text. 

The MSS Ground Segment, comprised of the CSF, DRRTS, MMF-M, MIPS, and TGS was 
turned over to NOAA on January 31, 1983. The TM Ground Segment, comprised of 
the MMF-T and the TIPS was turned over to NOAA on August 31, 1984. The 
Landsat-D Ground Segment is the largest and most complex facility of its kind 
ever constructed by GSFC. Both the MSS and TM systems met or exceeded all of 
their respective very stringent technical and operational performance 
requirements and were turned over to NOAA with no waivers or liens on 
capability or performance. 

The delivered Ground Segment consists of multiple computer systems 
interconnected by electronic data links. It is a totally new system 
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consisting of over 300 racks of equipment and over 1.4 million lines of 
software code. It Includes nine Digital Equipment Corporation (DEC) VAX 
11/780 computers, two DEC 20 computers, two PDP 11/34 computers, one PDP 11/23 
computer, four AP-180V array processors, two FFP array processors, and two 
laser beam film recorders, plus a large assortment of high-density digital 
recorders, image displays and special purpose high speed image processing and 
communications hardware. 

Photo II is a view of Ground Segment components under test at GE Lanham prior 
to installation in Building 28 at GSFC. 

The Ground Segment is partitioned into four facilities: an Image Generation 
Facility (IGF), a Mission Management Facility (MMF), a Control and Simulation 
Facility (CSF) including the Transportable Ground Station (TGS), and the 
Landsat Assessment System (LAS). 

Photo III shows the Ground Segment facilities. 

Image Generation Facility 

The Image Generation Facility consists of three subsystems: (1) Data Receive, 
Record, Transmit System (DRRTS), (2) MSS Image Processing System (MIPS), and 
(3) TM Image Processing System (TIPS). 

The DRRTS records incoming MSS and TM data and transmits MSS archival data to 
the EROS Data Center in Sioux Falls, South Dakota. DRRTS utilizes high 
density digital recorders, controlled by a DEC PDP 11/34, for recording of 
data and generation of directories containing data type, quantity and quality 
and selected parameters for use during the geometric correction process. MSS 
and TM data can be received directly from the Transportable Ground Station or 
relayed via DOMSAT from the TDRSS ground station in White Sands, New Mexico, 
or MSS data only on high density tape from the NASA and Canadian ground 
stations and re-recorded within DRRTS for compatibility with the MSS Image 
Processing System (MIPS). 
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PHOTO II. GROUND SEGMENT COMPONENTS UNDER TEST AT GE-LANHAM 






The MIPS consists of three identical processing strings (VAX 11/780 with a 
Floating Point Systems array processor) that produce partially processed MSS 
data, radiometrically corrected with geometric correction data included in the 
data format. The geometric correction data utilizes geodetic control points 
(identifiable Earth features) when available to register the data with respect 
to a map to within 0.5 pixel. The MIPS also has capabilities for in-depth 
online and offline performance evaluation and quality assessment. The MSS 
process flow is shown in Figure 6.0-3. 

The TIPS consists of two identical processing strings (VAX 11/780 with a 
General Electric FFP array processor) that produce fully corrected film and 
CCT products. The geometric correction process uses geodetic control points 
when available to register the data to a map within 0.5 pixel. The TIPS also 
has capabilities for in-depth online and offline performance evaluation and 
quality assessment. The TIPS processing flow diagram is shown in Figure 6.0-4. 

Mission Management Facility (MMF) 

The MMF consists of a DEC 2050 computer and a DEC 2060 computer. The DEC 2050 
is dedicated to MSS related functions and the DEC 2060 to TM related 
functions. Both systems are partitioned into four subsystems that perform 
user order processing, data base management, telemetry accounting and process 
control and report generation. User orders are received from the EROS Data 
Center, placed into the data base and used to schedule spacecraft 
acquisitions. Telemetry from these acquisitions is processed and forms the 
foundation for initiating process requests for the various steps of image 
processing. After the products are generated, the MMF initiates the requests 
for transmission of MSS data or shipment of TM products. 

Control and Simulation Facility (CSF) 

The CSF consists of four subsystems: Flight Operations, Performance 
Evaluation, Flight Scheduling, and Test and Simulation. The CSF utilizes 
three identical VAX 11/780 computers, linked together electronically, that can 
back one another up for redundancy. 
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Figure 6.0-3. Multispectral Scanner Image Generation Process Flow 
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Figure 6.0-4. Thematic Mapper Image Generation Process Flow 













j The Flight Operations subsystem is the interface between the operations and 
the spacecraft. The subsystem processes telemetry, displays it to the 
operator and formats and transmits commands. 

i 

The Performance Evaluation subsystem provides the analysis and graphics tools 
j to print, tabulate and plot telemetry points versus time. 

I 

t 

i 

The Flight Scheduling subsystem accepts candidate scene acquisitions from the 
MMF, processes these versus spacecraft and communication constraints, and 
generates a stored command load for the spacecraft. 

The Test and Simulation subsystem provides a hardware replica of the onboard 
computer (OBC) and a software simulation for the remainder of the Landsat 
I spacecraft. It is useful for rehearsing complicated procedures and validating 
both CSF and OBC software releases. 

Transportable Ground Station 

i 

The Landsat-D Transportable Ground Station (TGS) is a receive-only system. It 
j is capable of acquiring and tracking the Landsat-D series spacecraft and 
receiving the following spacecraft signals: X-band wideband data, S-band 

wideband data, and S-band narrowband telemetry data. The TGS demodulates and 
bit synchronizes received data. At its current GSFC location, wideband TM and 
MSS data are transmitted via cable modems to Building 28 for recording and 
further processing; narrowband telemetry and payload correction data are 
relayed to Building 28 via Nascom links in blocked data format. Antenna 
pointing information for acquisition and program track of the spacecraft is 
computed in the TGS from data provided by improved inter-range vector 
messages; upon acquisition of spacecraft signal, the system automatically goes 
into autotrack mode. The system includes a complete complement of test 

equipment for fault isolation and performance evaluation. 

Landsat Assessment System 

An R&D facility was provided consisting of data processing hardware and basic 
image processing software to serve as a resource for the investigation and 
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development of new Earth resources management and analysis techniques using 
data from the MSS and TM sensors. The LAS includes standard general purpose 
automatic data processing equipment, an array processor, special purpose image 
analysis equipment and a complement of both standard and unique software. The 
facility is designed to assess the performance of the MSS and TM instruments, 
the corresponding ground processing systems and to support development of new 
applications for MSS and TM data in managing the Earth's resources. 

EROS Data Center 

The Department of the Interior's Earth Resources Observation Systems (EROS) 
Data Center in Sioux Falls, South Dakota, is the focal point for gathering 
user requests far MSS and TM data acquisition, MSS product generation and MSS 
and TM product distribution and archiving. The requests are consolidated and 
forwarded to the Mission Management Facility at Goddard Space Flight Center 
where they become the bases for scheduling operation of the instruments and 
communications links. 
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6,1 MISSION MANAGEMENT FACILITY (MMF) 

The Mission Management Facility (MMF-M for MSS data; MMF-T for TM data) 
requirements were specified as part of the Data Management System (DMS) in the 
NASA specification. The major functions allocated to the MMF were: 

a. User request processing 

b. Image data production management 

c. Management reporting 

d. Data base management 

e. Control point library management 

f. Inventory control 

g. Data transfer. 

The user request processing function was partitioned into three categories: 

a. Mission planning 

b. Mission scheduling 

c. Acquisition accounting. 

Many of the requirements originally allocated to the mission planning and 
mission scheduling activities were reallocated to the Control and Simulation 
Facility (CSF) in an effort to reduce single-point-failure risks and to 
consolidate external interfaces related to Flight Segment operations into the 
CSF. The reallocated tasks associated with mission planning included: 

a. Long- and short-term predicted ephemeris processing 

b. Station contact processing 

c. Planned candidate request filtering 

d. Communication link notification. 

The reallocated tasks associated with mission scheduling included: 

a. Confirmed link support recording 

b. Predicted cloud cover entry 

c. Scheduled candidate request filtering. 
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Early in 1980, it was determined that the processing necessary to correct the 
spacecraft "jitter” would require a new subsystem to be added to the Ground 
Segment design. This Payload Correction Subsystem (PCS) was to be developed 
by Valley Forge analysis personnel and Lanham software personnel for 
implementation on the MMF host computer. The MMF system design was upgraded 
to accommodate PCS, resulting in a redefinition of some software modules, new 
software interfaces and upgrades of disk storage. At the same time, new MMF 
software modules were defined to maintain parameters required to support PCS 
and the band-to-band registration improvement in the TM image data processing 
algorithms . 

In May of 1980, NASA released Revision B of the GSFC Specification for the 
Landsat-D System (GSFC-430-D-100B), which defined all of the changes that 
resulted from the rebaseline activities caused by the redefinition of the 
Landsat Program. This specification levied numerous new requirements on the 
Ground Segment that impacted the MMF. However, the requirement to provide MSS 
and TM processing separability led to a major change in the Mission Management 
Facility configuration, with the christening of two systems: the MMF-M for 
MSS processing and the MMF-T for TM processing. 

Since the in-place design of the MMF included processing for both the MSS and 
TM data streams, the separation of sensor processing into two MMF systems 
resulted in a "cloning" of the MMF that would allow each system to be tuned to 
the unique specifications of its sensor's data processing. Likewise, each 
system could be adjusted to accommodate the unique processing requirements of 
the sensor's image processing system and payload correction subsystem. This 
separation led to a staggered development schedule with the MMF-M (the MSS 
system) being completed in December 1981 and the MMF-T (the TM system) in 
October 1982. The new Ground Segment configuration is depicted in Figure 
6.1-1. The MMF-M served as the single interface point to the CSF and the 
DRRTS. TM data flowing between CSF/DRRTS and the MMF-T was routed through the 
MMF-M by way of a switchable mass storage unit and computer compatible tape. 
This effectively decoupled the MSS processing from the TM processing and 
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Figure 6 . 1 - 1 . Ground Segment Configuration 



allowed for the planned handover of the MSS processing elements of CSF, IGF 
and MMF to NOAA in January 1983. The TM-unique processing elements of the IGF 
and MMF were to remain under NASA control until a January 1985 final turnover 
to NOAA. 

The MSS processing element was transferred to NOAA as planned on January 31, 
1983. However, the TM processing element was transferred to NOAA ahead of 
schedule, on August 31, 1984. 

6.1.1 HARDWARE CONFIGURATION DEVELOPMENT 

The General Electric Company had proposed a Digital Equipment Corporation DEC 
System 10 as the central processor for the MMF. This system was upgraded to a 
DEC System 2050 in 1979. With the program rebaseline of mid-1980, the MSS and 
TM functions were separated into two similar systems. The MMF-M system was 
centered around the DEC System 2050 and the MMF-T system was centered around a 
second DEC System 20. A DEC System 2040 was considered, but the DEC System 
2060 was eventually chosen due to the extra processing speed required to 
support payload correction processing. Both the MMF-M and MMF-T systems were 
equipped with off-the-shelf DEC peripherals, GE Terminet 300 printers attached 
to several KCRT stations, and Recognition Products OCR wands attached to the 
same KCRT stations. Both the MMF-M and MMF-T systems were eventually equipped 
with eight DEC model RP06 disk units and four DEC tape units capable of 
recording 800/1600/6250 bpi. The DEC 2050 system main memory final 
configuration was 512K 36— bit words, while the DEC 2060 system was upgraded to 
have 1024K 36-bit words of main memory. 

Figure 6.1-2 is a block diagram of the MMF-M hardware configuration. Figure 
6.1-3 is a block diagram of the MMF-T hardware configuration. 

Photo IV shows the DEC 2050 System in the MMF. 

6.1.2 SOFTWARE DEVELOPMENT 

The MMF software system design had been substantially completed at the time of 
the program rebaseline in 1980. The software system design was not 
substantially modified as a result of the rebaseline, but was "cloned" into 
MSS and TM software systems. This partitioning of the MMF-M and MMF-T allowed 
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Figure 6.1-2. MMF-M Hardware Block Diagram 










PHOTO IV. MMF SHOWING DEC 2050 SYSTEM 



the software and data base designs to be tailored to meet the requirements of 
the respective instrument processing systems. 

Each system was composed of four software subsystems: 

a. Request Support Subsystem (RSS) 

b. Flight Segment Management Subsystem (FMS) 

c. Ground Segment Management Subsystem (GMS) 

d. Data Base Administration Subsystem (DAS). 

A block diagram of the MMF software subsystems and their major functions is 
shown in Figure 6.1-4. 

The RSS was responsible for user request input, management reporting and 
inventory control. The FMS was responsible for processing user requests for 
spacecraft acquisitions, and for transfer of data to and from the Control and 
Simulation Facility. The GMS was responsible for image data production 

management, control point library management and transfer of data to and from 
the image processing systems. The DAS was responsible for data base 

management and transfer of data between the MMF-M and MMF-T systems. 

The MMF-M and MMF-T applications software was developed using top-down 

software development methodologies that imposed structured design, design 
walk-throughs, pseudo code, structured code and code walk-throughs. The 
majority of the MMF-M and MMF-T software was written in COBOL, with some 

Fortran, MACRO assembly language code and Interactive Query Language, a 
high-order report generation language. The MMF-M application software 
consists of approximately 270,000 lines of code and the MMF-T application 
software consists of approximately 280,000 lines of code. 

In addition to the applications software, both the MMF-M and the MMF-T 
employed operating system software, DECNET communication software and a 
CODASYL standard data base management system supplied by DEC. 
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The MMF-M and MMF-T software systems employed a distributed functional 
approach in that each executable process performed a single function. 
Multiple executable processes could be invoked back-to-back in a runstream to 
accomplish a major processing step. These individual executable processes 
communicated with each other by way of status (control) information in the MMF 
data base so that subsystem boundaries effectively disappeared. The operator 
interface to the executable processes and runstreams was originally conceived 
to be by way of specialized command files. However, a more generic and 
flexible multi-layered menu interface was developed, offering selection of 
functionally related processes. 

6.1. 2.1 MSS Mission Management 

6. 1.2. 1.1 Development 

Several change notices affecting the MMF— M development were implemented prior 
to system operation. One of the new requirements levied by the NASA D-100B 
specification was the capability to process MSS data collected at GSTDN 
sites. This requirement was complementary to another new requirement, that of 
processing data collected at up to eight foreign sites. These two 
requirements affected all subsystems of the MMF-M, but each impact was small 
and implemented quickly. 

A computer compatible tape interface to EROS Data Center (EDC) was also added 
to the MSS system. This was specified to be a two-way tape interface; MSS 
acquisition requests would be collected at EDC and periodically forwarded on 
an acquisition request order tape (AROT) to the MMF-M of the Ground Segment. 
The Ground Segment, specifically the MMF-M, would periodically generate an 
acquisition status information tape (ASIT) containing a snapshot of the user 
orders in the MMF-M data base and production status information for those user 
requests in process. 
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The end-to-end MMF-M operations fall into the following categories: 

a. Mission planning 

b. Mission scheduling 

c. Acquisition accounting 

d. Archive generation support 

e. Archive product verification support 

f. Archive product dissemination support 

g. Order closeout. 

In addition to the end-to-end MMF-M operations, the following support 
activities are present in the MMF-M: 

a. Performance evaluation product generation support 

b. Control point library maintenance 

c. Parameters maintenance 

d. Management reporting 

e. Inventory control 

f. Data base verification and utilities. 

6.1. 2.1. 3 Mission Planning 

The MMF-M mission planning activities begin with the entry of user standing 
orders for acquisition into the MMF-M data base. On a regular basis the 
standing orders are intersected with the expected flight path of the 
spacecraft. These planned candidate requests are written in a sequential 
file, merged with the TM planned candidate request file and staged for 
transfer, via DECNET, to the CSF. The planned candidate request file contains 
a nominal seven days of candidate requests. The planned candidate file is 
used by CSF to perform resource planning for image acquisitions. 

6.1. 2. 1.4 Mission Scheduling 

The MMF-M mission scheduling activities are almost identical to the mission 
planning activities. The same user standing orders from the MMF-M data base 
are examined and a scheduled candidate request file is generated, merged with 
the TM scheduled candidate request file and staged for transfer, via DECNET, 
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to the CSF. The scheduled candidate file contains a nominal 48 hours of 
candidate requests. The scheduled candidate file is used by CSF to perform 
resource scheduling and spacecraft commanding for image acquisitions. 

6. 1.2. 1.5 Acquisition Accounting 

After image acquisition is completed, the CSF returns three packages of 
information to the MMF-M: scheduled MSS and TM candidate request status, 

pre-processed selected MSS telemetry, and TM Payload Correction Data (PCD) 
directories. All three packages are transferred to the MMF-M via DECNET in 
the acquisition accounting activity. The actual PCD is forwarded to the MMF-T 
on magnetic tape. The MSS candidate information is segregated from the TM 
information and the MSS acquisition status is posted in the MMF-M data base. 
The TM candidate information is staged for transfer to the MMF-T. Scenes 
acquired for foreign site image processing are marked for closeout. Scenes 
acquired for image processing in the Landsat Ground Segment are forwarded to 
the archive generation support activity. 

6. 1.2. 1.6 Archive Generation Support 

The archive generation support activity encompasses a number of processes. 
First, the selected telemetry data is validated and staged for processing by 
the PCS. Once the PCS has completed the smoothing and attitude/ephemeris 
propagation, a telemetry directory is generated in the MMF— M data base. This 
directory is intersected with the list of scenes to be processed, which was 
supplied by the acquisition accounting activity. This intersection is then 
compared to recently received high density video tape directories to determine 
which scenes have video data present in the Ground Segment. Scenes to be 
processed that have sufficient telemetry and video data available are staged 
for processing by the PCS. Once the PCS has completed the generation of 
systematic correction data, the scene information is matched with selected 
control points from the control point library and placed on archive generation 
process requests. These requests are allocated to one of three MIPS strings 
for archive generation. After MIPS completes the archive generation task, the 
archive tape directory and associated feedback data are transferred, via 


22 


0990A 



DECNET, from MIPS to the MMF— M, where they are fhp process reauest 

Is closed out, and an archival "main image" data base entry is generated. 

6. 1.2. 1.7 Archive Product Verification Support 

Each archive product high density tape generated by MIPS is scheduled by the 
MMF-M for QA evaluation in MIPS. This is done by way of a process request 
generated from manual Inputs and the high density tape directory information 
from the MMF-M data base. The archive product verification process request is 
allocated to one of three MIPS strings, similar to the archive generation 
process request. Once the archive product verification task is complete, the 
MMF-M transfers, via DECNET, the associated feedback data for process request 
closure. 


6. 1.2. 1.8 Archive Product Dissemination Support 

Once the results of the archive product verification have been reviewed by 
operational quality assurance personnel, and release of the archive product is 
authorized, a process request for product dissemination is generated. This 
process request is routed to the DRRTS, which transmits the archival product 
data to the EROS Data Center. Once the transmission task is complete, the 
MMF-M transfers, via DECNET, the associated feedback data for process request 
closure. The MMF-M also generates a 9-track inventory tape containing 
pertinent information about the scenes transmitted. This inventory type is 
forwarded to another NASA facility for transmission to the EROS Data Center. 

6. 1.2. 1.9 Order Closeout 

Once the archive dissemination step has been completed, the corresponding user 
orders for acquisition and archive generation are updated to reflect 
successful completion. These standing orders remain open if the user 
requested more than one pass over the requested area in the user's specified 
time frame. Once the user's standing order is completely filled, or his 
specified time frame has expired, the order is closed. Standing orders for 
acquisition of data at foreign sites for foreign consumption are handled 
identically, except they undergo user order closeout processing immediately 
after the acquisition accounting step. 
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6.1*2*1.10 Performance Evaluation Product Generation Support 

The support of the performance evaluation product generation (PEPG) function 
involves retrospective order entry, the generation of process requests for 
PEPG and accounting for this PEPG processing. By mid-1980, much of the PEPG 
support software functions had already been designed and built as IM product 
generation software. In order to keep development costs down, this 
design/implementation was preserved. The retrospective PEPG product orders 
are closed out via the user order closeout step. 

6.1.2.1.11 Control Point Library Maintenance 

The control point library maintenance function involves accepting unsolicited 
scene-oriented candidate control point lists, generating control point library 
build (CPLB) process requests for the candidates and depositing the generated 
control points in the control point library. The latter function also has the 
capability to deposit unsolicited control points from the Landsat 2/3 control 
point library. 

6.1.2.1.12 Parameters Maintenance 

Static and volatile parameters are maintained in the long- and short-term 
parameter files separately for MIPS and for PCS. The long-term files contain 
stable values, such as voluminous row-dependent data, including nominal 
systematic correction data. The short-term files contain values that would 
change periodically, such as pole-wander data. Parameter values are entered 
by terminal input or, for row dependent data, by sequential file. Each 
parameter file of each type applies to a given period of time for which 
imagery was acquired. 

6.1.2.1.13 Management Reporting 

The management reporting area contains four major subcategories: 

a. Flight Segment reports 

b. Ground management reports 

c. Problem/def ect reporting 

d. Equipment service reporting. 
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The Flight Segment reports concentrate on potential acquisition candidate 
requests, actual candidate request status, spacecraft cycle acquisition 
statistics and acquisition maps. The ground management reports provide data 
on scenes in process in the Ground Segment, scenes in the archive on high 
density tapes, scenes on raw data tapes and image processing time lines 
statistics. The problem/defect report (PDR) processing system is built around 
a standalone data base of PDRs. This system includes entry/update and 
reporting software. Similarly, the equipment service report (ESR) processing 
system has its own data base, entry/update and reporting functions. Both the 
PDR and ESR systems were intended for development /operations management use, 
whereas the Flight Segment and ground management reports were intended for use 
by production control and operations management personnel. 

6.1.2.1.14 Inventory Control 

The inventory control system is built around its own data base and has its own 
entry /update software. It also has numerous reports for consumables and 
spares, such as suggested reorder list, overdue purchase orders list, master 
stock list, spares list, new purchase orders list and vendor code master 
list. The inventory control system maintains control over consumables and 
spares for both the MSS and TM portions of the Ground Segment. 

6.1.2.1.15 Data Base Verification and Utilities 

Data base utilities were developed to facilitate software 
development/integration, data base administration and operations. These data 
base unique functions include: common subroutines and copy files, data base 
load, data base unload, data base update and data base purge. The data base 
purge is most relevant to operations and basically removes old transient data 
from the data base. The data base update proved to be a valuable data base 
administrator’s tool for operations, as well as a valuable development/ 
integration tool. The data base verification functions are used for data base 
integrity checking. They include: chain chaser, area record summary and main 

image verifier. 
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6. 1.2. 2 TM M ission Management 


6.1.2. 2.1 Development 

After the mid-1980 rebaseline, several change notices affecting the MMF-T 
development were implemented prior to system operation. The first two change 
notices were implemented together, and comprised the Interim TM Data System 
(ITDS). The ITDS was partitioned into two subsystems, the TM Archiving 

Subsystem (TMAS) and the Accelerated Payload Correction Subsystem (APCS). The 
TMAS facilitated the TM data archiving period operations and the APCS, in 
conjunction with the TMAS, facilitated the Landsat TM early access period 
operations. 

Other changes incorporated during the MMF-T system development were the 
AROT/ASIT interface to EDC. This interface included TM product information 
(requests and request status) as well as TM acquisition information. Also, 
the requirements to generate TM high density tape (HDT) inventory tapes 
(GHITs) for partially processed TM imagery (HDT-AT) and fully processed TM 
imagery (HDT-PT) were deleted from the program. 

The final change notice required the capability to select for processing a 
subset of scenes from a single raw video tape, which had been archived via the 
TMAS. This function facilitated the TM R&D period operations. A summary of 
these periods and their processing requirements is shown in Table 6.1-1. 

After the launch and activation of Landsat 5, the TM Ground Segment finally 
began operating in the manner that was designed for the operational "January 
1985" system. Although some TM R&D tasks continued into this period, the 
processing scenario was one of processing all scenes acquired to archival tape 
(HDT-AT). 


6.1. 2. 2. 2 TM Data Archiving Period 

Since the TM Ground Segment development was partitioned away from the MSS 
Ground Segment development, and since the TM Ground Segment development was 
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Table 6.1-1. TM Data Processing Periods Summary 


PERIOD 

FROM 

TO 

PRODUCTS 

VOLUME 
(SCENES /DAY) 

TM DATA ARCHIVING 

16 JUL 82 

FEB 83 

TM LIBRARY TAPE 

APPROX. 70 

LANDSAT TM EARLY 

JULY 82 

JULY 83 

SYSTEMATIC CORRECTION 

1 

ACCESS SYSTEM 



DATA TAPE 


TM R&D 

1 AUG 83 

6 SEP 83 

HDT-AT 

3 




HDT-PT 

3 




241 MM FILM 

3 




CCT 

1 


7 SEP 83 

27 SEP 83 

HDT-AT 

6 




HDT-PT 

6 




241 MM FILM 

6 




CCT 

1 


28 SEP 83 

18 OCT 83 

HDT-AT 

9 




HDT-PT 

9 




241 MM FILM 

9 




CCT 

2 


19 OCT 83 

5 APR 84 

HDT-AT 

12 




HDT-PT 

12 




241 MM FILM 

12 




CCT 

2 

LANDSAT 5 

6 APR 84 

- 

HDT-AT 

100 

OPERATIONAL 



HDT-PT 

50 

SYSTEM 



241 MM FILM 

50 




CCT 

10 
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scheduled for completion over a year after the launch of Landsat-D, the TMAS 
was developed. The TMAS performed the following functions: 

a. Mission planning 

b. Mission scheduling 

c. Acquisition accounting 

d. Raw data archiving 

e. Management reporting. 

The mission planning, mission scheduling and acquisition accounting functions 
of the TMAS were almost identical to the corresponding functions in the MMF-M 
and MMF-T. 

The raw data archiving function created a library of correlated video tape 
directory information, PCD information and scene information from which the 
NASA Science Office could select scenes for subsequent product generation by 
way of the Landsat TM early access system and later, by the TIPS. The 
management reporting function was centered around a single report that 

itemized the contents of the raw data library. This reporting function was 

later upgraded to provide a commentary field that could be updated, on a scene 
or interval basis, with processing suitability information, such as data 
quality or cloud cover. 

The TMAS was modified during the early operations phase to allow raw video 
tapes collected at Prince Albert, Canada, to be processed. These changes 
became a permanent part of the final "full TM” MMF-T system. 

6. 1.2. 2. 3 Landsat TM Early Access System Period 

NASA had planned the development of a Landsat TM early access system to be 

comprised of parts of the Landsat Ground Segment and a NASA-developed 
Applications Data Development System (ADDS). This system, known as Scrounge, 
generated low— volume (one scene per day) engineering TM products using raw TM 
video data collected by DRRTS and TM Payload Correction Data (PCD) processed 
by CSF. The PCD was converted to Systematic Correction Data (SCD) by the 

Accelerated Payload Correction Subsystem (APCS) of the 1TDS. The APCS was 
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engineering personnel. The heart of the APCS was the engineering code 
prototype of the algorithms that would eventually be implemented as the 
operational TM Payload Correction Subsystem (PCS). 

6. 1.2. 2. A TM R&D Period 

During the period of time that the TIPS system was operating at less than full 
capacity, the MMF-T provided process requests for selected scenes by way of a 
"bridge” between the ITDS raw data and the acquisition accounting activity of 
the "full TM" MMF-T system. This "bridge” software facilitated the gradual 
increase of production volume during the TM R&D period. 

6. 1.2. 2. 5 Operational System 

The end-to-end MMF-T operations fall into the following categories: 

a. Mission planning 

b. Mission scheduling 

c. Acquisition accounting 

d. Archive generation support 

e. Initial product generation support 

f. Final product generation support 

g. Archive /product verification support 

h. Product dissemination support 

i. Order closeout. 

In addition to the end-to-end MMF-T operations, the following categories of 
support activities are present in the MMF-T: 

a. Control point library maintenance 

b. Parameters maintenance 

c. Management reporting 

d. Data base verification and utilities. 

6. 1.2. 2. 6 Mission Planning 

The functions performed in the MMF-T mission planning activity are the same as 
those performed in the MMF-M system, except that the resultant planned 
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candidate request file is also staged for transfer across the switchable disk 
to the MMF-M. 

6. 1.2. 2. 7 Mission Scheduling 

The functions performed in the MMF-T mission scheduling activity are the same 
as those performed in the MMF-M system, except that the resultant scheduled 
candidate request file is also staged for transfer across the switchable disk 
to the MMF-M. 

6.1.2. 2.8 Acquisition Accounting 

The MMF-T acquisition accounting activity begins with the transfer of the 

segregated TM candidate request status files and the TM PCD directory files 
across the switchable disk from the MMF-M. The TM candidate request status is 
posted in the MMF-T data base, in a process functionally equivalent to the 
MMF-M processing. 

6. 1.2. 2. 9 Archive Generation Support 

Many of the processes of the MMF— M archive generation support activity were 
reworked for TM data processing. Only two new processes were added: the TM 

PCD directory ingest program and the TM systematic correction data (SCD) tape 
generation program. Control point selection is done on a wholesale 

primary /secondary control point chip basis, so the "selection" process is 
embedded in the control point library maintenance activity. In addition to 
these, the following unique requirements of TM were incorporated in the 

archive generation support processes: the TM PCD stream (32 Kbps) is in a 

different format than the selected data from the MSS telemetry (8 Kbps); the 
raw video tape directory data includes mirror scan correction data (MSCD); the 
TM archive generation process is interval oriented versus scene oriented. 

These, along with the accuracy requirements of the TM mission, drove the 
development of a totally new and more complex payload correction subsystem, 
which is embedded in the archive generation support activity. 
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6.1.2. 2.10 Initial Product Support 


The image generation process of generating a high density, fully processed 
initial product (HDT-PT) from the high density partially processed archive 
product (HDT-AT) does not exist in the MSS Ground Segment. The support 
activity consists of recording standing and retrospective requests for 
products, generating process requests for HDT-AT to HDT-PT processing and 
recording the HDT-PT directory /feedback information in the data base. 

6.1.2.2.11 Final Product Generation Support 

The final product generation activity is a continuation of the production 
control functions begun in the initial product generation step. This activity 
is identical to the MMF-M PEPG support activity, except that the TM product 
mix differs from the MSS PEPG product mix. Also, the order entry may be for 
standing orders or retrospective orders and is part of the initial product 
support activity. 

6.1.2.2.12 Archive/Product Verification Support 

This activity, similar to the MMF-M archive product verification support 
activity, controls the TIPS data quality function by generation of process 
requests and by processing the process request feedback. In addition to 
supporting HDT-AT verification, this activity supports HDT-PT, CCT-AT and 
CCT-PT verification. 

6.1.2.2.13 Product Dissemination Support 

This activity is functionally equivalent to the archive product dissemination 
support activity in the MMF-M. However, the products being disseminated are 

24lmm film roll masters and CCT-AT/CCT-PT original tape sets. This is 
accomplished by generation of paper process requests and shipping information 
that accompany the product to one of two shipping facilities (one for film, 
one for product CCTs). For film shipments, a roll inventory tape is generated 
that contains pertinent scene information. The inventory tape is shipped with 
the associated film rolls. Once shipment is complete, the annotated process 
request information is fed back into the MMF-T for process request closure. 

% 
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6.1.2.2.14 Order Closeout 


The order closeout activity for acquisition and archive generation orders 
takes place after the archive generation support activity and is identical to 
the order closeout activity in the MMF-M. For product orders, the order 
closeout occurs after product dissemination. Standing orders for products are 
handled the same as standing orders for acquisition. Retrospective product 
orders are immediately closed out after product dissemination. 

6.1.2.2.15 Control Point Library Maintenance 

The MMF-T control point maintenance differs from the MMF-M activity in that 
control points are selected and processed on sets of contiguous scenes. This 
activity also performs a selection function by identifying all "primary” 
control point chips for use in archive generation. The capability to update 
the control point directory data, including the selection flag, is also 
provided. The MMF-M capability to ingest Landsat 2/3 control points was not 
implemented in the MMF-T, since those missions did not carry the TM instrument. 

6.1.2.2.16 Parameters Maintenance 

Long- and short-term parameter files are generated for TIPS and PCS, as is the 
case in the MMF-M, but the content of the 1M files differs greatly from the 
MSS files. The TIPS long-term file contains mostly radiometric correction 
parameters. Earth modeling data and other constants. The TIPS short-term 
parameter file contains active/substituted detector information, TIPS 
processing parameters and pole-wander data. The PCS long-term parameter file 
contains TM sensor/detector constants, telemetry calibration data and Earth 
modeling data. The PCS short-term parameter file contains only 
active/substituted detector information and pole-wander data. 

The MMF-T has an additional capability to "modify" existing parameter files by 
updating a copy of the existing parameter file and marking the existing 
parameter file as inactive. The capability to install radiometric correction 
parameters by tape is provided, along with the standard terminal input mode. 
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6.1.2.2.17 Management Reporting 


The management reporting area is almost identical to that of the MMF-M 
system. Only one additional report, the unprocessed 1M PCD tape report, was 
developed. Most of the reports contain minor cosmetic changes to reflect the 
different characteristics of the TM sensor and the different aspects of the TM 
image processing system. 

6.1.2.2.18 Data Base Verification and Utilities 

As one might expect, the utility "building block” subroutines developed in the 
MMF-M were virtually unchanged for use in the MMF-T system. The data base 
load, unload and update functions were modified to be consistent with the 
MMF-T data base schema, which diverged from the MMF-M data base schema due to 
the unique TM sensor characteristics and TM image processing requirements. 
The data base purge process was substantially re-designed, due to the 
retrospective processing nature of Landsat 4 data. Substantial performance 
improvements were also realized as a result of the re-design. A read-only 
data base examine function was added to the MMF-T data base utilities area. 
The data base verification functions were also upgraded to be consistent with 
the MMF-T schema. 
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6.2 CONTROL AND SIMU LATION FACILITY 

The Control and Simulation Facility (CSF) provides for Ground Segment (GS) 
control over the Flight Segment (FS) operations. As the controlling element, 
it is responsible for FS health and safety as well as the proper scheduling 
and configuring of both flight and ground elements to permit payload data 
operations. To perform its task the CSF serves as the single location for FS 
telemetry processing and command generation (Figure 6.2-1). In addition, it 
supports external interfaces required for Landsat flight operations, such as 
orbital computation support and data communication link scheduling. 

Several different factors acted as driving elements for the eventual design 
and development of the CSF. Table 6.2-1 provides a summary of a few of the 
more important inputs. The final results of these inputs are a CSF design 
that is much different from that of previous Landsat missions, and a 
development effort that was conducted simultaneously with newly evolving 
flight and ground elements. 

The development schedule followed by the CSF reflected the continual major 
changes within the Landsat Program itself. As proposed in 1978, the CSF was 
envisioned as a modification of the earlier Landsat 1, 2 and 3 control center 
concepts with enhancements for performance improvements, especially in the 
area of hardware systems. This baseline was continually modified, in response 
to requirement redefinitions and system performance goals, and was never fully 
settled until the rebaseline period of late 1980. At that point the system 
hardware was finalized and the software design concept was developed. 
Although minor modifications continued to arise, the final system that 
currently supports Landsat 4 and 5 operations was formed directly from the 
program rebaseline concept. The final schedule followed by the CSF is shown 
in Figure 6.2-2. 

The remaining paragraphs within this section provide a more detailed 
discussion of the respective hardware and software development efforts. 
Direct comparisons between the proposed and delivered systems are presented 
with additional details on what factors forced the changes. Despite the 
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Figure 6.2-1. CSF Top-Level Beteline Concept 
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Table 6.2-1. 

Key Influences On CSF Design 

DRIVING FACTOR 

IMPACTS 

Telemetry data formats & rates 

- 8 Kbps R/T, 32 Kbps OBC/PCD 

- 128/256 Kbps NBTR 

Significant data rate and volume increase 
beyond 1 Kbps standard of 1970s 
Combined data rates of 136 (8 + 128) Kbps 
possible through TDRSS 

Onboard computer and flight 
software 

Allows for extended autonomous operation but 
at price of extensive critical software 
table generation 

Management and understanding of software 
critical to successful flight operations 

Flight segment communication 
systems 

- multiple use of S-band 

channel 

- multiple paths for payload 

data 

Mutually exclusive use of single channel by 
OBC, PCD and NBTR complicates operational 
scheduling 

Selection of appropriate transmission path(s) 
for payload data is receiving site(s) 
dependent - simultaneous multiple paths 
often required 

TDRSS use for communication 
support 

Management of steerable antenna aboard FS 
requires extensive planning to maintain 
correct pointing 

Scheduling requirements of TDRSS are very 
different from those of previous GSTDN 
systems 

Simultaneous dual spacecraft 
operations 

Required increased hardware capability and 
impacted software systems designs 
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Figure 6.2-2. CSF Development History 








difficulties caused by this continuous evolutionary system design, the CSF 
successfully provided its required functions at all of the mission critical 
points. The July 1982 Landsat 4 launch and the March 1984 Landsat 5 launch 
were both successfully supported, as have been their activation and continuing 
operational phases. In addition, the CSF has supported the first operational 
use of the Network Control Center (NCC) and the other Tracking and Data Relay 
Satellite System (TDRSS) elements, 

6.2.1 HARDWARE CONFIGURATION 

The originally proposed CSF hardware configuration was based on the 
development and operational concepts existing at that time. However, like 
most other Landsat-D systems, it went through numerous changes before a final 
configuration was formulated. This final design, while performing the same 
generic control center functions as originally proposed, was very different 
from that originally conceived. 

Figure 6.2-3 shows the originally proposed CSF hardware system. The basic 
concept behind this design was to operate a single spacecraft with 
communications through the TDRSS network. Capture of the real-time telemetry 
was critical to allow image processing and thus redundant online systems were 
required. Advance planning and user order information was also required to 
ensure total accountability of acquisition since the concept was to acquire 
only "ordered" data. Thus, the third dedicated computer system for mission 
management . 

The redundant flight operation systems utilized PDP 11/70 computers, each 
having 256 KB of memory, a single 176 MB disk drive and two STC 1600/6250 tape 
drive units. Output to hardcopy was available through either the dedicated 
Versatec printer/plotter device or to shared resources of a line printer, drum 
plotter, chart recorders or graphics terminal. Display consoles were 
switchable to either computer and utilized ISC 8051 color display terminals. 
External communications for telemetry, command, etc., were handled through the 
specially-built signal conditioning and switching unit (SC&SU). To allow 


38 


0990A 



* 



Figure 6.2-3. Proposed CSF Hardware Configuration 











status evaluation of the payload instruments, a Ouick Look Display, including 
decommutation devices for each sensor, was included. 

The mission management computer consisted of a single PDP 11/70 with 512 KB of 
memory, two 176 MB disks and four tape drive units. Three units were high 
data STC devices, while a single 800 bpi unit was included to maintain 

external interface compatibility. Hardcopy output was through a dedicated 

Versatec unit, a dedicated line printer or the shared drum plotter. The 
expanded memory and disk drive systems were mandated by the user data required 
to support mission planning and processing control. To support user insight 
into their orders, a modem was provided to allow dial-in user inquiries. 

Supported by the mission management computer, but utilized primarily for 
flight operations development support, was the simulation interface unit. 

This unit, in conjunction with software in the 11/70, provided a real-time 

simulation of the FS to supply realistic telemetry and command responses. 
Within the simulation unit was an actual ground version of the flight 
computer, capable of executing the flight code without change. Also included, 
to provide an interface to the flight computer, was a simplified command data 
handling system, similar to that aboard the spacecraft. This design was used 
to ensure that timing considerations were met. Utilizing the 11/70 to 
simulate the external world and spacecraft subsystems, and the simulation unit 
to execute flight code, a complete real-time simulation could be supported to 
provide inputs to the flight operation systems. 

As a final note, all three mainframes were to be electronically interconnected 
for data file transfers. 

Figure 6.2-4 shows the final configuration utilized to support Landsat 4, and 
provided to NOAA as part of the January 1983 turnover. Although a quick 
comparison shows that a three system ring concept was retained, very few of 
the hardware elements had not been revised. The system design uses three 
identical VAX 11/780 systems, each having 3 MB of memory; one dedicated and 
two shared 176 MB disks; and three dedicated tape units. The disks are 
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Figure 6.2-4. Final CSF Hardware Configuration 





































arranged to nominally utilize three drives for each system, with the 
possibility of using up to five at any time. While the drives are 
dual-ported, thus easing switching, they will not support simultaneous access 
from two computers. Hardcopy output is available through dedicated Versatec 
units or line printers or through shared chart recorders or a drum plotter. 
Display consoles have increased by one, to a total of four, with the terminals 
being switched to monochrome VT100 units. Communication support through 
Nascom is now handled through the A-channel units, with the switching unit 
being downscoped to eliminate any data processing. Finally, the payload 
monitor was reduced in complexity by removing the respective decommutation 
hardware and providing a simple sensor data display scope. 

Photo V is a view of the CSF System including the VAX 11/780. 

The previous mission management system was reallocated, partially to the MMF 
(paragraph 6.1), and the remaining scheduling functions supportable by any 
available CSF VAX system. 

One unit remaining fairly consistent was the simulator hardware. While the 
interface unit required adaptation to connect to the VAX, the concept of 
hardware /software simulation remained unchanged. Also unchanged was the 
electronic interface between systems to support data transfers. Now, however, 
an additional interface was supported to the MMF-M computer to permit data 
transfers for request scheduling and telemetry processing. 

The following paragraphs provide further details into the specific history of 
each major hardware element and explain how the final approach was reached. 
Within each element a chronological presentation is made. Also, references 
back to Table 6.2-2 are made as appropriate. 

6.2. 1.1 Automatic Data Processing Equipment (ADPE) 

As a common grouping, this refers to all of the standard computers and their 
peripherals, including the mainframes, memory units, disk drives, tape drives, 
printers and display units. Excluded from this section is the computer 
equipment within the simulator, as it is special purpose hardware. 
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PHOTO V. CSF SYSTEM SHOWING VAX 11/780 


The original computer selection of 11/70 mainframes was driven by the 
following factors: 

a. Processing requirements 

b. Availability of hardware and software 

c. Commonality through the GS with DMS. 

The memory and disk drives were selected for meeting the expected computation 
and data load of the single 8 Kbps telemetry rate. Also considered was the 
historical mission management data base, which required extra storage space 
for the one system. Where possible, due to relatively low usage rates, the 
equipment was shared to minimize excessive cost. 

By late 1978/early 1979 the Data Management System (DMS) design, the other 
M half” of the GS, had been revised and their needs had outgrown the 11/70 
computer. Also, a new DEC minicomputer, the 11/780, was introduced. To 
accommodate the DMS requirements a switch was made to the new 11/780 and, to 
maintain GS commonality, the CSF followed. This commonality was intended to 
save operating costs and, by upgrading systems, make available much new 
technology and increased performance. The decision to upgrade was completed 
by March 5, 1979, and presented as the baseline at the Conceptual Design 

Review. 

The next major ADPE modifications were directed in December 1979 and January 
1980. The former change was the addition, to both of the two online telemetry 
processing systems, of additional memory capacity and an additional disk 
drive. This change was made to accommodate processing of the PCD input 
required to correct thematic mapper image data. The latter change was made to 
correctly handle the newly added FS telemetry recorder data. The original 
concept of utilizing TDRSS real-time communication was being delayed by its 
late development. Narrowband recorders were incorporated within Landsat to 
support the GSTDN operations. Additional hardware requirements defined at 
this time included computer memory, another disk drive per system and a third 
tape drive for the two machines. 
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The final major hardware reconfiguration occurred with the rebaseline 
activities of September 1980. The program rebaseline was designed to support 
simultaneous dual spacecraft operations, which brought about several 
modifications. The first redesign was to provide three duplicate systems to 
provide real-time support to both spacecraft while retaining a "hot back-up" 
capability with the third string. Scheduling and non-real-time processing 
could be done either between passes on the prime machines or on the back-up 
computer. 

A few months prior to Landsat 4 launch, a MIPS machine was configured (via 
system software parameters) to be used as a fourth CSF VAX. Software, testing 
and FS support personnel made extensive use of the fourth machine, both before 
and after the launch. 

The original display system to be utilized in the CSF included 19-inch color 
display CRTs. The display software built for the CSF Includes color parameter 
definition areas so that the operator could fully utilize the color capability 
in the CRTs for building displays. The selection of the color terminals in 
the CSF was based on terminal specifications versus requirements and cost. 
The terminals that were selected were manufactured by Industrial Data 
Terminals (IDT). The model selected for use in the CSF was one of IDT's newer 
designs and many problems resulted during the acceptance period. The problems 
with the terminals resulted in a return of the terminals to the manufacturer 
and the installation of DEC VT100 terminals as the primary CSF terminals. 
With a blend of purchasing and leasing, the number of terminals required for 
development, operations and system testing was achieved. 

6. 2. 1.2 A-Channels 

The baseline Landsat design provided for an interface to Nascom that consisted 
of three message— switched, full-duplex links carrying 4800 bit messages. 
These links would transmit telemetry and command data with real spacecraft 
data on one line and simulated data on another. The third line was to be used 
as a spare. The signal conditioning and switching unit (SC&SU) was designed 
to switch any one of these three duplex lines to any of the three VAX 11/780 
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computers. Block synchronization was to be performed by the SC&SU while frame 
synchronization was to be performed by the software in the VAXes. Figure 

6.2- 5 shows the original configuration of the Nascom-to-VAX interface. 

In 1979, the interface between the networks and the Ground Segment changed 
from three full-duplex lines to five duplex and three simplex lines. These 
new lines now brought the configuration to eight input lines and five output 
lines. With the addition of the extra lines, and other new requirements in 
the interface, a redesigned Nascom interface was proposed. As shown in Figure 

6.2- 6, this system consists of an SC&SU with greater switching capability and 
a series of A-channels connected in series with the VAX computers. 

The A-channels are part of a system developed by Ford Aerospace for use in 
Goddard Project Operations Control Centers (POCCs). This system, called the 
Telemetry and Command (TAC) computer, is based on a DEC PDP 11/34 computer. 
Due to the uniqueness of the Landsat 4 requirements, the design of the TAC was 
modified to include only the A-channels for Landsat. The Ford design was 

chosen to: 1) take advantage of the standardized Nascom interface design, and 

2) to utilize the software already developed. The processing to be done by 
the PDP 11/34 in the TAC would be done by the VAXes in the CSF. Table 6.2-2 
shows the basic capabilities included in the A-channels. 

The CSF system was developed so that control and set up parameters for the 
A-channels could be entered by a controller in the CSF Mission Operations Room 
(MOR). Parameters that are unique to specific stations or operations could be 
stored in catalogs and recalled when needed. The front panel of the 
A-channels contained status indicator lights. These lights showed data block 
presence and data lock status through illumination of red, yellow and green 
lights. Prior to the launch of Landsat 4, these indications were remoted to a 
panel in the MOR. They provided the operations staff with a quick and 
accurate indication of the incoming and outgoing data links. 

A view of the Spacecraft Command Console is shown in Photo VI. 
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Figure 6.2-5. Baseline CSF Nascom Interface 
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Figure 6.2-6. Rebaseline Nascom Interface 




Table 6.2-2. NIF Capabilities Summary 


• A-CHANNELS - FOUR PER COMPUTER - ONE PER NAS COM LINE 

- DETECTS NASCOM BLOCKS (INCOMING) 

- ERROR CHECKS NASCOM BLOCKS (INCOMING) 

- MINOR FRAME SYNCHRONIZATION (INCOMING) 

- CORRELATES MINOR FRAME SYNC/GROUND RECEIVED TIME (INCOMING) 

- DISCARDS UNWANTED BLOCKS (INCOMING) 

- TRANSFERS NON-TELEMETRY BLOCKS, FRAME SYNCHRONIZED TELEMETRY, 
AND STATUS RESULTS TO COMPUTER (INCOMING) 

- METERS BLOCKS (OUTGOING) 

- ADDS ERROR DETECTION CODES TO BLOCKS (OUTGOING) 

- CONVERTS DATA PCM CODE FROM NRZ-L TO NRZ-M (OUTGOING) 
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6. 2. 1.3 Matrix Switch 


The interface between the CSF and the outside world is through Nascom lines. 
These lines are connected and routed within the CSF by means of the signal 
conditioning and switching unit (SC&SU). When the number of Nascom lines 
Increased from three to eight, the SC&SU had to be modified. The redesign of 
the unit included the use of a matrix switch. The requirements for the matrix 
switch were that there would be no single point of failure for Flight Segment 
support. This requirement mandated a certain amount of redundancy for the 
switch. In order to keep the cost of the switch down, a design was chosen 
that gave functional redundancy. Engineers in Valley Forge designed and built 
the switch. 

The switch could be configured automatically through software or manually with 
switches in the Mission Operations Room. As the operations became better 
defined in the period prior to the Landsat 4 launch, it was apparent that the 
design of the switch caused two problems: 1) Because of the limited number of 
routing options there was a lack of flexibility of configurations. This often 
caused delays in software development and offline processing due to the high 
priority of real-time operations. 2) The complexity of the switch, along 
with configurations of the A-channels, often resulted in the selection of 
wrong data paths with resultant delays or data losses. 

To alleviate these problems, another switch was installed by Nascom in front 
of the matrix switch. This new switch allowed switching of any input and/or 
output line into any of the inputs to the old matrix switch. This 
configuration was used to support the testing, launch and operation of Landsat 
4, including the interfaces with TDRSS, which could require up to four lines 
at the same time. The addition of the new switch added another step to the 
routing of the data within the control center so that the possibility of 
operator error in configuration increased. Because of this and the 
anticipation of Increased switching operations to support the two spacecraft 
system, the NOAA contractors added a new switch for the launch and operation 
of Landsat 5. This new switch replaced the Nascom switch and the matrix 
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BiHfch. This new conf -Cguraffon has been used to support flight operations 
since January 1984. 

6. 2. 1.4 C&DH Simulator 

The original design of the Landsat control center called for a spacecraft 
simulator that would be used for testing and training. The design chosen 
consisted of a hybrid simulator that was part flight hardware and part 
software resident in the CSF computers. The flight hardware included in the 
simulator consisted of a modified version of a multi-mission spacecraft and 
data handling module, including the onboard computer (OBC). This design was 
chosen so that operations personnel could accurately test changes to the 
flight software for accuracy and timing. Figure 6.2-7 shows the configuration 
of the hardware portions of the simulator. The design of the simulator 
remained virtually the same throughout the program. The unit was 
subcontracted to Fairchild to design and assemble. 

The system worked to specification when completed. However, the uniqueness of 
the equipment maintenance problems contributed greatly to simulator downtime. 
The simulator was supposed to model the Flight Segment as closely as possible 
and, due to evolution of the Flight Segment hardware and software, the 
simulator itself was constantly being updated. This, coupled with an evolving 
ground support system that was required for testing, caused the simulator to 
be behind schedule in many of the training and CSF verification activities. 
The complexity of the spacecraft itself often required the support of flight 
engineers to properly model parameters in the simulator. This requirement, 
however, was secondary in priority to the time-critical activities associated 
with preparing the spacecraft for launch. 

The full-up use of the simulator required two CSF VAX computers. One computer 
was used to host the simulation software, while the other was used to function 
as the Interfacing flight operations computer. This resource consumption 
prevented active use of the simulator after the launch of Landsat 4. It was 
not until the call-up of Landsat 5 for launch that the simulator system was 
used again. 
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Figure 6.2-7. C&DH Simulator Configuration 






















6. 2.1.5 Support Hardware 

Contributing to the hardware configuration of the CSF were other pieces of 
equipment besides the major components described previously. The significant 
units were the drum plotter, the Mission Planning Terminal (MPT) and the Quick 
Look Monitor. 

The drum plotter, or Houston plotter, was a mechanical plotting device 
utilizing three colored pens to plot telemetry data for both long- and 
short-term trends. This unit was connected to the CSF computers through the 
SC&SU and could be switched to any one of the three VAXes. The plotter itself 
contained a microprocessor that utilized plot instructions from the main CSF 
computers. Because of the resource crunch associated with the launch of 
Landsat 4, the plotter was connected to a MIPS computer so that engineering 
analysis could be accomplished without impacting real-time operations. The 
drum plotter provided precise and accurate information. However, it had two 
major drawbacks: 1) It was slow. The time required for a complete set of 

orbital plots could exceed 45 minutes once the plotter started. 2) It was 
noisy. The mechanical plotter impacted communications within the CSF because 
of its sustained high level of noise. It was often turned off during key 
operations activities. The plotter was finally moved to another area. 

The Mission Planning Terminal (MPT) is the system used to support the Network 
Control Center scheduling interface. When it became apparent there was a 
requirement to support TDRSS service scheduling, a trade was made between 
building a system within the CSF computers and utilizing a GFE system, the 
MPT. It was decided to utilize the MPT for the following reasons: 1) The 

interface was undefined, so that the effort to support that interface could 
not be defined. 2) Code 500 of GSFC was developing a system that would 
support the interface. 3) It would be cost-effective to utilize the GFE 
system due to the scheduled delivery date for the MPT and its software in 
effect at the time the decision was made. The Landsat Project Office procured 
two MPT systems so that scheduling redundancy could be achieved. The MPT 
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systems consist of a color terminal, a CPU, a disk drive and a printer. One 
Nascom full duplex line was utilized for the MPTs, with a switch that could 
control the transmit side of the terminal. The terminals were programmed by 
Landsat personnel with the proper identification and configuration codes. 
These terminals successfully supported the first Landsat/TDRSS tests in 1983. 

The Quick Look Monitor (QLM) in the CSF was used by CSF operations personnel 
to get an early indication of instrument data and of the health of the 
instrument. The CSF part of the QLM consisted of an oscilloscope and a 
printer along with processing and routing hardware. The Data Receive, Record 
and Transmit System (DRRTS) could route selected MSS and TM data (one channel 
at a time) to the QLM in the CSF. This equipment provided valuable 
information to the subsystem engineers during activation and other critical 
data acquisition periods. 

6.2.2 SOFTWARE DEVELOPMENT 

The CSF software consists of five major elements plus system support 
software. The major elements of CSF software are shown in Figure 6.2-8. As 
in hardware development, the software development in the CSF was evolutionary 
over the course of the program, with major impacts including the selection of 
a Data Base Management System (DBMS) and the addition of Network Control 
Center interfacing software. The software development was also Impacted by 
design growth changes as the complexity of the system was better understood. 
The development followed the guidelines as defined in the Software Management 
Plan. 

Even though there was a constant evolution of requirements, the sizing of the 
software and the development estimates were consistent with the end results 
for the overall CSF. Table 6.2-3 shows the estimates that were developed for 
the CSF design review of September 1980 as compared with the actual results 
from September 1983. 

After the launch of Landsat 5, modifications to CSF software became 
necessary. These modifications were mainly in the areas of software 
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increased. Since many of the functions in the CSF are data base driven, the 
system could support both spacecraft by having the software access the 
operator defined data base through initialization procedures. 

6. 2.2.1 Flight Operations 

The Flight Operations Subsystem (FOS) is made up of the components listed in 
Figure 6.2-9. The primary purpose of this software is to handle the real-time 
command, control and communications operations of the CSF. To handle the 

operator interactions of these functions, a special purpose language was 
developed for Landsat. This language is a part of FOS and is called CSF 
Operator Interface Language (COIL). COIL is based on the GSFC developed 
Systems Test and Operations Language (STOL). The major differences are 
additions to handle Landsat-unique situations. COIL is a high-order language 
that gives the operator the capability to utilize directives and procedures to 
configure hardware and software and perform all of the required support 
operations necessary for data acquisition. The FOS software was used 

successfully to support both Landsat 4 and 5 launches, along with all the 
tests and training that were required in system integration. FOS processes 
consumed a large amount of CPU resources, thereby limiting terminal operations 
on any single VAX. Performance enhancements made between the launch of 

Landsat 4 and the launch of Landsat 5 gave the CPUs the capability needed to 
perform all functions on one computer. 

6. 2. 2. 2 Performance Evaluation 

The Performance Evaluation Subsystem (PES) is a collection of software that 
performs analyses on the telemetry data from the Landsat Flight Segment. 

Figure 6.2-10 is a structure diagram of the PES software. Many of the PES 
reports were based on the analysis tools used in the Landsat 1-3 control 
center that became proven standards for determining spacecraft health. The 
development of operational software was contingent on completion of the FOS 
system and the inclusion of all required data base parameters in the resident 
data base. Since many of these functions were not ready until the period just 
before Landsat 4 launch, the PES development was not complete until after the 
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Figure 6.2-9. Flight Operations Software 
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Figure 6.2-10. Performance Evaluation Subsystem Structure 



launch of the spacecraft* Because uf tills , changes aim improvements recruited 
In the PES system competed for resources with all the other launch support 
functions. 

The PES is designed to be a user-defined tool for short- and long-term 
capability that can be initiated manually or through a COIL procedure* Many 
COIL procedures were developed for PES to support subsystem activation along 
with anomaly analysis* 

A form of plotting using the Versatec printer was developed by the engineers 
at Valley Forge and installed in the CSF between the launch of Landsat 4 and 
Landsat 5. This tool provides rapid turnaround for investigation of 
parameters contained in narrowband tape recorder dumps* The Houston plotter 
provides better resolution in a multi-color format* However, due to the 
design of the software for the plotter and the slow speed of the plotter 
itself, rapid turnaround was not a strong point of Houston plots. 

The PES software provides most of the data utilized for offline analysis along 
with most of the information contained in activation and performance reports. 
The system has proven to be extremely valuable in the support of spacecraft 
emergencies and recovery investigations. 

6. 2. 2.3 Test and Simulation 

The Test and Simulation (TSIM) software consists of two parts: real-time 
simulation and simulation support. Figure 6.2-11 shows the contents of these 
two TSIM modules. As mentioned previously, TSIM development was dependent 
upon Flight Segment development and information from Flight Segment 
Engineers. Because of this need, TSIM software development to the operational 
level was behind schedule. It took the combined efforts of Ground and Flight 
Segment engineers to resolve problems so that the system could be used for 
launch simulations. 

Scenario checkpoints were a part of the TSIM software and the simulator could 
be brought up in either a launch or on-orbit mode. The capability to develop 
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because of the heavy emphasis on launch configurations and the previously 
mentioned schedule problems. 


6.2. 2.4 Mission Scheduling 

Mission scheduling in the CSF was performed by the Flight Scheduling Subsystem 
(FSS) software. The FSS performs the steps necessary to provide a 
conflict-free schedule of Flight Segment activities. These steps include the 
preparation for the scheduling operation, the actual scheduling operation and 
post-pass acquisition analysis of Flight Segment events. Figure 6.2-12 shows 
the contents of the three major software groups that perform these steps. The 
baseline of the FSS has changed considerably since the original design. The 
first major set of changes were attributable to: 

a. FSS/FMS Reconfiguration - the original allocation of functions 
between the CSF/FSS and the MMF was re-evaluated and changes were 
implemented in the FSS design. 

b. NCC/TDRSS/GSTDN - the Network support area for data acquisition 
services was undefined. The original concept of all TDRSS services 
was changed because of delays in the TDRS system. 

c. Onboard Tape Recorders - due to the delays in the TDRSS, onboard 
recorders were added to record the 8 Kbs telemetry data. The 
acquisition of tape recorder data added complexity to the FSS in that 
a narrowband tape recorder management scheme had to be added. 

d. TM Jitter - due to the TM jitter, a compensating process was added. 
This process consisted of a new 32 Kbs data stream that contained 
Payload Correction Data (PCD). This data was used in the image 
processing system to compensate for the jitter caused by the mirror 
movement. PCD transmission was required whenever TM was activated 
for imaging. Additionally, whenever PCD was being transmitted, it 
precluded the transmission of OBC dump data or tape recorder dump 
data. 

e. ICDs - the ICDs between Landsat and the Network/OCG were still in the 
negotiation phase so needed parameters for FSS could not be obtained 
until after the ICDs were complete. 
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Figure 6.2-12. Flight Schedule Subsystem Software 





The development of the FSS continued to lag behind schedule until the approach 
of the Landsat 4 launch. During this period, the importance of the FSS to 
operations mandated that recovery tiger teams be formed. These teams worked 
around the clock until the FSS was in condition to support operational 
activities after launch. 

One of the driving factors that dictated the basic philosophy for the 
scheduling system was whether data acquisition would be through ground station 
(GSTDN) or through TDRSS. The original design called for a system based on a 
full-up (2) TDRS system. Slips in the TDRSS schedule resulted in requirements 
for a GSTDN only design. This caused a major redesign of the FSS. The 
differences in the nature of support for the full TDRS FSS designs precluded a 
mixed FSS system. The result was two separate scheduling systems in the CSF, 
one for GSTDN only and one for full-up TDRSS. After NASA launched the first 
TDRS, there was a need for a limited TDRSS FSS. This need, along with the 
limited power available on Landsat 4 due to a solar array problem, resulted in 
the development of the interim scheduling system for one satellite TDRS 
support. This interim system was never in full operational use for the 
following reasons. The problems that occurred in the launch of TDRS -A caused 
a deferral of the second TDRS launch. Coupled with this, the network was 
undergoing extensive acceptance testing of the TDRS system. As a result, the 
CSF has been utilizing the GSTDN FSS for the majority of both Landsat 4 and 
Landsat 5 scheduling needs, and manually modifying the schedule whenever a 
TDRS support was added. 

6. 2.2. 5 Network Interface 

The original baseline design of the CSF did not call for a special subsystem 
to deal with the Network interface. However, once the impact of the NCC/TDRS 
system was understood, the requirement arose for a software system to handle 
the newly-identified Interface. The Network Control Center Subsystem (NCCS) 
is the software subsystem designated to handle the message traffic between the 
NCC and the CSF. This subsystem's structure is shown in Figure 6.2-13. The 
format and content of the messages to be handled were agreed to in an ICD with 
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Figure 6.2-13. Network Control Center Subsystem Structure 
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scheduling and the MPT. This interface is required because all of the TDRS 
scheduling requests and actual schedules are transmitted and received through 
the MPT. This information is entered in the FSS process so that the schedules 
can be produced without conflict. 

The majority of NCCS operations are real-time support functions. These 

support messages are data base defined for format and operator defined for 
variable content. The NCCS was used extensively for NCC interface testing and 
successfully supports the actual TDRSS acquisitions. 

6. 2. 2. 6 Data Base 

The CSF data base is not a separate subsystem within the CSF software. It is 
software that supports the other subsystems by storage and manipulation of 
parameters. The CSF data base is significant in that the original design of 

the CSF did not have a DBMS. During early 1980, when the impact of the NCCS 

proposal was being studied, various alternatives were being examined to 

provide data file storage and access. Since the VAX computers selected for 
the CSF were a relatively new system there was little historical data upon 
which to base a decision. The Digital Equipment Corporation (DEC) had not yet 
developed a VAX based DBMS so an outside vendor was sought. After a 

performance study was completed, a DBMS called SEED, developed by 

International Data Base Systems, was selected. Although the cost of 

implementing SEED in the CSF was expensive due to the vendor price, DBMS was 
installed because of the pressing need for a data base manager and the 

anticipated performance improvements. Along with SEED, support software was 
acquired from the vendor for a query language (HARVEST), an on-line 
interactive data manipulation language (GARDEN) and a transaction processor 
(SPROUT). The SEED data base was used in FSS, FOS and NCCS and provided a 
structured storage and retrieval system for the CSF. 

Although SEED provided a powerful tool for CSF software development, problems 
were encountered. The first problem was that SEED was complicated to use. 
The data base administrator (DBA) was required to build and load the system. 
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This position retired extensive training and personnel turnover resulted in 
the DBA being behind the curve in the development area. The second major 
problem area was the lack of documentation in the structure of the data base. 
This information could have helped the subsystem engineers in the input 
definitions for the data base. The third major problem area was the access 
speed of data base interactions. This problem severely hurt the run duration 
of the Flight Scheduling System because of the FSS need to store and access 
thousands of bits of data for each scheduling run. 
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The Data Receive, Record, Transmit System (DRRTS) functions were specified as 
part of the Data Management System (DMS) in the NASA specification. The major 
functions allocated to DRRTS were: 

a. Receive and record Landsat 4 multispectral scanner (MSS) and thematic 
mapper (TM) data on high density tape (HDT). The sources of the data 
for MSS were: 

1. Transportable Ground Station in real-time at 15.06 Mbps 

2. Tracking and Data Relay Satellite System (TDRSS) in a bent pipe 
mode; i.e., real-time through the TDRSS satellite to White Sands 
and retransmitted to GSFC via Domsat. 

3. 14-track HDTs from foreign sites. 

The sources of the data for TM were: 

1. Transportable Ground Station in real time at 84.9 Mbps 

2. Via TDRSS at 1/2 real-time rates. The White Sands TDRS receive 
site records TM data in real-time and later retransmits it to 
GSFC via the Earth synchronous domestic satellite (Domsat) whose 
maximum bandwidth is 50 MHz. 

3. 28-track HDTs from Prince Albert, Canada 

b. Transmit MSS archive data to the EROS Data Center at 15.06 mbps 

c. Copy MSS and TM high density tapes, either unprocessed or processed 

d. Generate tape directories for MSS and TM unprocessed tapes, which 
include mirror sweep correction data for TM, and send to the Mission 
Management Facility 

e. Extract MSS/TM sensor data and send to the Control and Simulation 
Facility (CSF) for a Quick-Look Display 

f. Store MSS/TM in a tape archive (short-term). 

The hardware configuration of DRRTS as implemented is shown in Figure 6.3-1. 
6.3.1 HARDWARE DEVELOPMENT 

General Electric originally proposed a Digital Equipment Corporation PDP 11/03 
as the controller for the DRRTS hardware. This was changed to a PDP 11/34 for 
increased capability in memory, speed and software development tools. The 
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Figure 6.3-1. Data Receive, Record, Transmit System Hardware 
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functions and a menu-driven operator display. DRRTS control software was 
implemented in approximately 23,000 lines of code (LOC). 


DRRTS was proposed to be the central recording facility for the DMS, 
controlling high density recorders for image processing along with performing 
the functions mentioned above. The control of the image processing recorders 
was moved to the image processing strings (MIPS and TIPS) to simplify 
development and testing. The design of DRRTS was ultimately limited by the 
11/34 capabilities for extracting and storing data. 


General Electric originally proposed five 14-track and five 28-track high 
density digital recorders (HDDR) built by Bell & Howell to be the high-speed 
recording medium in DRRTS. This evolved to five 14-track and five 42-track 
recorders built by Martin-Honeywell to be compatible with existing NASA 
purchases and therefore reduce costs. After the record /playback function for 
each processing string was moved, DRRTS had the following HDDR configuration: 
two 14-track, two 28-track and two 28-track (expandable to 42-track) built by 
Martin-Honeywell. The recorder design included error correction capability 
and had better performance than the bit error rate specifications. The 

28-track recorders were capable of recording data rates up to 85 Mbps. 
Pre-selected speeds were designed in the DRRTS recorders to allow them to 
record the various data rates required (15.06, 30.12, 45.18, 42.2 and 84.4 
Mbps). These recorders are synchronized to the data rates by external 
programmable frequency sources. The 28-track system also included a timing 
subsystem to generate and read IRIG times on the tape, and a tape search unit 
that enabled computer or local control of the recorder system. 

The DRRTS special purpose hardware consisted of two MSS demultiplexers built 
by MacDonald-Dettwiler, plus one TM demultiplexer, one matrix switch and one 
MSS/TM demultiplexer built by General Electric. As originally proposed, one 
type of demultiplexer was to be used for both MSS and TM. However, separating 
the MSS and TM processing permitted use of MSS demultiplexers that were 
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purchased es of f-the-shelf harHwarp. Increasing the reliability of the MSS 
processing. 

The TM demultiplexer was a state-of-the-art design to extract information 
necessary to generate a tape directory from the incoming TM data stream. It 
included sophisticated logic to account for bit slips and sync losses and 
additionally had a separate subsampled video display that allowed early visual 
confirmation of data quality. A TM/MSS demultiplexer furnished extracted 
sensor data for a quick-look monitor used for monitoring detector performance. 

The matrix switch was the electrical interface between recorders and the 
demultiplexers. It was designed to switch both digital data and analog timing 
signals from/to any recorder to any demultiplexer. It also included built-in 
loop back test capability to validate the operability of the receiving 
terminal equipment for the White Sands and EDC links. 

DRRTS contained an MSS data simulator built by MacDonald-Dettwiler and a TM 
data simulator built by General Electric. Both devices, augmented by test 
tapes obtained during spacecraft testing, were used for validating both 
hardware and software during development and provide operational capability 
for fault isolation. 

Photo VII is a view of the DRRTS System. 

6.3.2 SOFTWARE DEVELOPMENT 

The DRRTS software structure is shown in Figure 6.3-2. It includes the 
RSX-ll/M operating system, a Fortran IV-Plus compiler, and the DECNET 
networking software supplied by DEC. An extension of this vendor software, 
the DRRTS system software, was developed in-house. The system software 
includes hardware device drivers for non-DEC supplied hardware and associated 
hardware diagnostic software. 

The operator interface program controls all CRT displays and hard copy 
devices, the printing of HDT labels, as well as the reading of labels via an 
optical character reader, and allocates resources to various DRRTS functions 
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PHOTO VII. DRRTS SYSTEM 
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Figure 6.3-2. DRRTS Software Conceptual Design 
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line tests of the various communications links to and from the DRRTS. 


directs 


The operations monitor program controls the progress of multiple operations, 
displays status and error messages for the operator via the operator interface 
program and controls the generation of HDDT directories. 


The high density digital recorder (HDDR) control program directly controls the 
HDDRs. It processes their status and generates any resulting status and error 
messages. It also generates quality files for quality assessment of the tapes. 


The MMF service program controls the DRRTS side of the MMF to DRRTS interface 
using vendor - supplied DECNET software. It handles the higher level of MMF to 
DRRTS file exchange protocol, generating alerts when new process requests 
enter DRRTS and providing appropriate request feedback to the MMF. 
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The MSS Image Processing System (MIPS) performance and production requirements 
are shown in Tables 6.4-1 and 6.4-2, respectively. The overall processing 
flow is shown in Figure 6.4-1. The input to the MIPS is a 28-track high 
density tape recorded in the DRRTS. The data is stored on disk after 
reformatting. Geometric and radiometric corrections and other annotation data 
are computed. The image data is then radlometrically corrected, with tables 
included for geometric corrections, and written to a 28-track archival tape 
that can be evaluated before it is returned to DRRTS for transmittal to the 
EROS Data Center. 

Three identical processing strings (Figure 6.4-2) are provided. One spare 
28-track high density digital recorder is switchable to any processing string. 

MSS Payload Correction 

The Payload Correction Subsystem (PCS) processes telemetry data to produce 
geometric correction functions that correct for systematic errors in the 
imagery. This process is performed on the DEC 2050. It involves the 
smoothing, validating and propagating of both the attitude and ephemeris data 
followed by the generation of scene correction data (scene center, location 
and identification) and transformation of the data to a standard coordinate 
system. 

MSS Archive Generation 

The MSS Archive Generation (MAG) function generates partially processed data 
and MSS data products from unprocessed image data. The data processing steps 
that are performed to accomplish this include radiometric and geometric 
correction, ancillary data generation, manual cloud cover assessment and 

generation of 70 mm film for quality assurance inspection. 

The process begins with the receipt of a process request (PR) from the MMF or 

an operator generated engineering request. The PR specifies those intervals 

(up to 35 contiguous scenes) of data on the 28-track high density tape that 
are to be processed. MAG then reads the MSS correction parameter file 


73 


0990A 


Table 6.4-1. MSS Image Processing Performance Requirements 


REQUIREMENT 

MSS PROCESSING SYSTEM 

TURNAROUND TIME 

48 HOURS MAXIMUM 

• RAW DATA TO 
ARCHIVAL HIGH 
DENSITY TAPE 

• WITH ANY SINGLE 
POINT FAILURE 

MAXIMUM UTILIZATION 

85% OF 16 HOUR DAY 

RADIOMETRIC ACCURACY 

♦ 1 QUANTUM LEVEL 

MAP PROJECTIONS 

SPACE OBLIQUE MERCATOR 
UNIVERSAL TRANSVERSE 
MERCATOR/POLAR . 
STEREOGRAPHIC 

RESAMPLING ALGORITHMS 

CUBIC CONVOLUTION 
NEAREST NEIGHBOR 

GEOMETRIC ACCURACY* 

• TEMPORAL REGISTRATION 

• GEODETIC 

03 PIXEL (90% OF THE TIME) 
03 PIXEL (90% OF THE TIME) 


♦WITH SUFFICIENT CORRELATABLE GROUND CONTROL POINTS 
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Table 6.4-2. MSS Image Processing Production Requirements 
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Figure 6.4-2. MSS Image Processing System Hardware 
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Next, MAG extracts subsampled image data, for each interval of data read from 
the HDT-RM, for manual cloud cover assessment and 70 mm film generation. This 
subsampled data is used for reference to assess the overall quality of the 
image data on the HDT-RM. Next, control point neighborhoods, calibration 
wedge values and histograms for the geometric and radiometric correction data 
processing functions are obtained from the image data and the radiometric 
correction tables, geometric correction matrices and ancillary data for the 
image data are produced. Finally, MAG generates the archival high density 
tape (HDT-AM) and the process request feedback to the MMF. Data is read from 
the disk, the radiometric corrections are applied in the array processor and 
then it is sent through the Parallel to Serial Data Output (PSDO) device and 
the matrix switch to write to the HDDR. 


The radiometric and geometric functions are both calculated in the AP 180 
Array Processor. Data is read from disk to the array processor and written 
back to disk. Cloud cover assessment is an operator interactive process that 
displays the subsampled images to the operator and solicits response for the 
estimated percentage of cloud cover for each image on a quadrant basis. 


MSS Performance Evaluation and Product Generation 

The MSS Performance Evaluation and Product Generation (PEPG) function provides 
the capability to evaluate archival high density tapes or produce film and 
computer compatible tape (CCT) products for the evaluation of the computed 
correction data. These processes can be Initiated via a PR from the MMF or 
locally by the operator. 

The archival high density tape is read from the HDDR, through the matrix 
switch and Serial to Parallel Data Input (SPDI) to disk. Both partially 
corrected (CCT-AM) and fully corrected (CCT-PM) tapes can be generated along 
with performance evaluation reports and Comtal image displays. 
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High resolution fils (241 mm) could also be generated by t-h<« nroress using 
the TM Image Processing System (TIPS) hardware. 

MSS Control Point Library Build 

The MSS Control Point Library Build process is used to create a library of 
both geodetic and supplemental control points in the MMF. If available for 
the scenes to be processed, these control points are included in the MAG PR 
and are automatically used in the geometric correction process. They allow 
the radiometrically corrected archival data to be corrected to a 0.5 pixel 
geodetic registration accuracy and a 0.3 pixel temporal registration 
accuracy. The process of building the Control Point Library includes: 

a. Scene Selection - The priority of scenes from which to select control 

points is made by the NOAA Program Office based upon the current 

content of the Control Point Library and anticipated program needs. 
Cloud free scenes of high digital quality are selected by interactive 
examination of the MMF data base and examination of quality 
assessment 70 mm film files. 

b. Selecting Candidate Geodetic Control Points - Up to 25 

well-distributed candidate geodetic points (GCPs) are selected 
representing features observable on both 241 mm film and standard 

maps. The location of each GCP is marked on the map. 

c. Digitizing Candidate Control Points - The latitude and longitude of 
all GCPs are located to within 0.37 mm using a sonic digitizer. On 
standard USGS 1:24,000 scale maps this corresponds to an accuracy of 
0.16 pixel. The MIPS collects information on all candidate GCPs in a 
scene and transmits that information to the MMF. 

d. Control Point Generation - The process of selecting control points is 

an interactive one, utilizing radiometrically corrected imagery 

overlayed with annotated maps to locate supplemental control points 
to augment the geodetic control points. 

6.4.1 HARDWARE DEVELOPMENT 

The MSS image processing automatic data processing equipment was substantially 
changed from that originally proposed. The proposed system had a Digital 
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Federation of Functional Processors (FFP) that performed the image processing 
algorithms. There were two strings each capable of processing either MSS or 
TM data. 


The PDP ll/70s were replaced with DEC VAX ll/780s after a trade study showed 
that additional speed and capability using the 32-bit architecture could be 
realized with little cost or schedule impact. The system still used FFPs for 
data decommutation and geometric correction. When the MSS processing 
functions were separated from the TM, the FFPs were replaced by an 
off-the-shelf array processor (AP-180V), the VAX compatible version of the 
AP-120B. 


The high density digital recorders (HDDRs) used in MIPS were identical to 
those 28-track HDDRs used in DRRTS. The recorders are controlled directly 
from the VAX utilizing the tape search unit. IRIG times can be read from or 
written to the tapes using the timing subsystem. The speed is controlled by 
externally programmable frequency synthesizing. The MIPS strings have a spare 
HDDR that can be switched to any string. 

The MSS system uses Comtal 512 x 512 pixel displays. These displays are used 
to verify system performance, examine image quality and assess cloud cover for 
archive generation and the PEPG process. 

The MSS Decom built by MacDonald-Dettwiler synchronizes to the MSS data 
stream, extracts the time code from the data, performs line length 
calculations, extracts the calibration and detector data, and demultiplexes 
and reformats the detector data for input to the VAX 11/780. The synchronizer 
portion is identical to that in the DRRTS demultiplexer, the Decom adds a 
buffer memory. This function was originally proposed to be done by a 
decommutator built by General Electric that could be used for both MSS and 
TM. This approach was abandoned in favor of the commercially available MDA 
decom when the 1M and MSS functions were separated. 
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The SPDI and PSDO perform the serial and parallel conversions and data 

buffering functions between the computer and the HDDR. 

As proposed there was one Dicomed 70 mm film recorder shared between two 
strings. As implemented there is one for each string. 

Figure 6.4-2 shows this layout. Photo VIII shows the hardware. 

6.4.2 SOFTWARE DEVELOPMENT 

The MIPS software structure shown in Figure 6.4-3 logically grouped functions 
and allowed for separate software development teams. The bulk of the MIPS 
software was written in Fortran. It consisted of approximately 157,000 lines 
of code. 

Three different kinds of software were utilized in MIPS: applications 

software, developed by GE, vendor-supplied software, and system software, 

developed by GE to support non-standard peripheral devices. 

Additionally, parameter files were designed and used to supply values of time 
variant and invariant constants. 

6.4.2. 1 APPLICATIONS SOFTWARE 

6.4. 2. 1.1 MSS Control and Communications 

The Control and Communication Package (CCP) software executes independently on 
each MIPS string to control basic string operations, communicate with MMF and 
handle individual work items. The software is arranged as an executive 
process with numerous supporting processes. Each supporting process provides 
a single, specific service to the executive process. Since most of these 
supporting processes are complex data processing functions, performing them 
separately reduces the complexity of the executive substantially. 
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PHOTO VIII. MI PS-2 HARDWARE 
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Figure 6.4-3. MIPS Software Structure 
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The MSS Archive Generation Package process includes the following major 
functions : 

a. The image data ingest function provides the capability to input image 
data from unprocessed high density tapes and store it on disk. 

b. The data extraction function extracts control point neighborhoods, 

calibration wedge values, and histograms for the geometric correction 
and radiometric correction data processing functions. It also 
extracts subsampled image data for use by the MCCA and QA functions. 

c. The radiometric correction data generation function generates 

radiometric look-up tables. 

d. The geometric correction function, utilizing perturbations computed 

by the payload correction function, generates geometric correction 
data. Both systematic correction, taking into account only 
spacecraft position and attitude, and corrections using control 
points from the Control Point Library may be produced. 

e. The ancillary data processing function formats header, annotation, 

ancillary and trailer data. 

f. The HDT-AM output function controls writing the image and other data. 
6. 4. 2. 1.3 MSS Performance Evaluation Product Generation 

The MSS Performance Evaluation Product Generation (PEPG) Package contains 
several major functions: 

a. The image data ingest function provides the capability to input image 
data, from various magnetic tape medium, and temporarily store it on 
disk. 

b. The geometric correction function provides the processing required to 
prepare a corrected CCT product. 

c. The Comtal display function provides the capability to display a 
selected scene or portions thereof on a Comtal video display. 

d. The performance evaluation report function provides results of 
performance evaluation of functional capabilities including scene 
comparison, radiometric and geometric correction verification. 


83 


0990A 


C I t\ 1 /. 

V. * t* X. T 


won n 4.--1 n^.4^1- T 4k 

L’l*J iJ wil llux x wxui. >/ 


Di.41 J 

— i 

The MSS Library Build software assists the MIPS operator in the selection of 
control points to be sent to the MMF for placement into the Control Point 
Library. 


6. 4. 2. 1.5 MSS Quality Assurance Film Generation Package (QAF) 

The QAF package allows production of 70 mm latent film images of a single 
selected band from each scene recorded on an HDT— AM during archive tape 
generation. 


6. 4. 2. 1.6 Manual Cloud Cover Assessment Package (MCCA) 

The MCCA package allows an operator to view subsampled images on a Comtal 
image display unit from up to two bands of each scene and to then enter 
estimates of the percentage of cloud cover for each of four quadrants. 

6. 4. 2. 1.7 MIPS Applications Utilities 

This is a set of utility software functions that are used by the major 
software programs. 

6. 4. 2. 2 Vendor Supplied Software 

Vendor supplied software was supplied by two vendors: Digital Equipment 

Corporation (DEC) and Floating Point Systems, Inc. (FPS). 

Three major packages of software were purchased from DEC to support the MIPS. 
They are the VAX/VMS Operating System including all of the associated support 
software, the Fortran IV Plus compiler along with all of the associated 
library functions, and finally, the DECNET Communication software. 

Four major packages of software were purchased from FPS to support the AP-180 
Array Processor. They are the software to support DEC VMS along with all 
associated support software, the software necessary to write and debug 
assembly language programs, the AP math library software and the software 
containing Fortran callable routines which perform various image processing 
functions on the AP-180. 
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6.4. 2.3 System Support Software 

Software programs (drivers) not connected with specific application packages 
were developed to control special designed hardware peripherals used in the 
MIPS strings. Associated with each driver is a program to exercise the driver 
and the hardware. The exercisers are not designed for hardware diagnostics, 
although in most instances they were useful for limited functional testing. 

In addition, primitive device drivers and exercisers were developed for each 
of the basic interfaces used in the MIPS string. These devices are the 
DR11-C, DR11-B, DR70 and the GE-built special peripheral interface (SPI). 
These primitives allowed the demonstration of the most basic communication 
capabilities of the device. The primitives were developed first, before the 
full drivers and exercisers were written. This allowed easier integration of 
hardware and software by eliminating complex user, operating system and driver 
software from a new device. 

6.4. 2.4 MIPS Production Parameter Files 

A parameter is a constant that is widely used throughout MIPS, or a variable 
whose value determines or restricts the operation of the MIPS software. MIPS 
provides for changing parameter values. Parameters must be updated from time 
to time to correspond to changes in the Flight Segment. These changes are 
brought about by gradually changing conditions, such as sensor degradation. 
Earth magnetic field changes, or mission events, such as orbit adjustments. 

Most of the MIPS parameters affect the image data processed by MIPS in some 
way and are identified as production parameters. Other parameters that do not 
affect the image data but do control the efficiency of MIPS operation are 
classed as operational parameters. The operator may alter operational 
parameters to improve system efficiency without concern for degrading the 
quality of the image products. Changes to the production parameters, however, 
must be made with care, since the quality of the image data changes 
accordingly. To distinguish the production parameters from the operational 
parameters, the parameters are stored in separate files. 
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MIPS production parameters and their history are maintained by the MMF. The 
MMF transfers these parameter files over DECNET or by using the CCT backup to 
DECNET. The operational parameters are maintained locally on the MIPS string 
and are transparent to the MMF. 
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6.5 TM IMAGE PROCESSING SYSTEM 


The TM Image Processing System (TIPS) performance and production requirements 
are shown in Tables 6.5-1 and 6.5-2, respectively. The overall processing 
hardware is shown in Figure 6.5-1 and the flow is shown in Figure 6.5-2. 

The input to the TIPS is a 28-track high density tape (HDT-RT) that was either 
recorded in DRRTS or received from another NASA or Canadian station. 
Computations are made for geometry, radiometry and annotations. These are 
written to a 28-track archival tape (HDT-AT), which can be subsequently 
selected for further processing of one or more scenes through TIPS to generate 
241 mm film, CCT-ATs and CCT-PTs. 

Designs for this system underwent four revisions after the original proposal 
was made in October 1977. They are identified as VAX Upgrade System (December 
1978), FFP Decom System (February 1980), Jitter System (May 1980) and the 
current Rebaseline System in September 1980. 

The TIPS rebaseline system defined in September 1980 was the system built and 
delivered to NOAA in September 1984. The functions, hardware and software of 
that system are described in the following paragraphs. 

TM Payload Correction 

The TM Payload Correction Subsystem (PCS) processes payload correction data 
(PCD) downlinked by the Landsat Flight Segment to produce systematic 
correction functions that correct for known errors in the imagery. In this 
section, PCD specifically refers to the data contained in the 32K bit/second 
Q-channel telemetry output by the Landsat Flight Segment. 

PCS is performed in two phases. This is because the PCD must be accompanied 
by the mirror scan correction data extracted from the corresponding TM image 
data in order to be fully processed. The two data streams are received over 
different paths, and may be acquired by the Ground Segment at different 
times. Phase 1 processes the acquired PCD as much as possible without the 
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Table 6.5-1. TIPS Performance Requirements 
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Table 6.5-2. TIPS Production Requirements 
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Figure 6.5-1. TIPS Hardware Architecture 












mirror scan correction data. Phase 2 completes the processing when the mirror 
scan correction data is available. 

PCS Phase 1 

TM telemetry data (32 bit/second, Q-channel telemetry) is acquired from the 
Flight Segment via Nascom by the CSF. The CSF extracts the necessary data, 
packages it, and routes it to Phase 1, via CCT post acquisition. PCS Phase 1 
performs the following processing: 

a. Calibration, validation, enhancement and smoothing of the PCD. 

b. Determines modes. 

c. Filters, interpolates, and combines ADS and DRIRU samples into a 
coherent attitude estimate. 

d. Models the ephemeris data based on a simplified orbit model and 
propagates least squared error ephemeris estimates. 

The output is a time-ordered sequence of Flight Segment attitude estimates, 
ECI ephemeris estimates and TM instrument modes, for TM instrument operational 
periods. This data is saved as processed TM payload correction data (PCD), to 
await extraction of the corresponding intervals of mirror scan correction data. 

PCS - Phase 2 

When mirror scan correction data is available. Phase 2 completes processing 
the processed TM PCD. PC Phase 2 generates systematic correction functions 
that correct for known errors in the image data. These functions incorporate 
corrections for: 

a. Detector to detector misregistration 

b. Band to band misregistration 

c. Sensor misalignment 

d. Knowledge of ephemeris 

e. Knowledge of attitude 

f. Non-linear mirror profile 

g. Earth rotation 

h. Map projection 
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i. Jitter 

j. Scan line corrector nonlinearity. 


TM Archive Generation (TAG) 

When TM system correction functions are available for imagery acquired on 
HDT-RT, TM archive generation (TAG) may proceed. 

TAG Preprocessing Calculations 

TAG preprocessing computes the locations of CPNs in line and pixel coordinates 
(the locations are supplied in coordinates of latitude and longitude). 

TAG First HPT Data Pass (Pass 1) 

The TAG First HDT Data Pass extracts data from the HDT-RT for use in 
subsequent processing. TAG Pass 1 extracts TM radiometric calibration data 
and histograms of the TM scene data. TAG Pass 1 extracts neighborhoods about 
the expected locations of control points in the TM scene data, called Control 
Point Neighborhoods (CPNs). TAG Pass 1 extracts mirror scan start time, line 
length and quality information from every line of TM data. TAG Pass 1 
extracts subsampled image data, in several bands, from the TM image data. 

TAG Calculations Phase (CALC) 

For the data extracted by Pass 1, TAG CALC phase performs the following 
processing: 

a. Radiometric function calculation 

b. Control point neighborhood processing 

c. Geodetic correction improvement 

d. HAAT and line support data generation. 

The CALC phase calculates radiometric correction functions from the TM 

radiometric calibration data and histograms of the TM scene data. TAG CALC 
phase performs control point neighborhood processing on the extracted CPNs. 
The CALC phase optionally uses the extracted CPNs and control point chips to 
improve the accuracy of the system correction data produced by PCS. Finally, 
the CALC phase generates radiometric correction lookup tables, header, 
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ancillary, annotation and trailer (HAAT) data and line support data for the 
HDT-AT. 

TAG Second HPT Pass (Pass 2) 

The Second TAG HDT Pass (Pass 2) generates the HDT-AT tape. For each interval 
of data to input on HDT-RT , TAG Pass 2 copies the HAAT section to HDT-AT, then 
inputs the raw data from the HDT-RT and performs the following processing. 
Pass 2 radiometrically corrects the raw data by applying the appropriate 
radiometric correction lookup table, reformats the data from BIP to BIL, and 
writes the data to HDT-AT. During this pass, TAG also extracts neighborhoods 
about the expected locations of candidate control points and subsampled image 
data. 

Cloud Cover Assessment (CCA) 

TAG Cloud Cover Assessment operates in two modes - interactive and automatic. 
In interactive mode, CCA displays framed images of subsampled image data 
extracted by TAG to an operator, and accepts an operator estimate of cloud 
cover for each quadrant of the displayed image. In automatic mode, CCA 
calculates cloud cover estimates for the TM scene data by applying an 
assessment algorithm to the subsampled image data extracted by TAG. 

70 mm Film Generation 

This function accepts data sets containing subsampled TM imagery generated by 
TAG and generates a 70 mm film product. Each input scene is reformatted to 
band-oriented format and output to a film image on a film roll. The images 
are gridded, annotated and partially geometrically corrected, with fixed 
corrections. 

TM Initial Product Generation 

This function generates an HDT-PM containing geometrically corrected image 
data in one of three map projections. The input to this function is an HDT-AT 
containing radiometrically corrected image data and geometric correction 
information. The geometric correction is accomplished by reading the 
information from the HDT-AT and using the geometric correction operator in the 
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FFP to resample the image data. Both cubic convolution and nearest neighbor 
resampling algorithms are available. This function must also convert the 
image data from BIL format to BSQ format. 

TM Final Product Generation 

This function generates 241 mm film or 1600/6250 bpi computer compatible tapes 
from an HDT-PT or from an HDT-AT . CCT products may be in either BSQ or BIL 
format. Either full scenes or quadrants may be available on CCTs and all 
quadrant scenes are digitally mosaicable. 

TM Data Quality Assessment 

TM Data Quality Assessment allows any TM digital product to be read and 
evaluated. 

TM Control Point Library Build (TCL) 

TM Control Point Library Build accepts an HDT-PT (and directory) and a 
candidate control point list, and extracts the required scenes from the 
HDT-PT. At this point, TCL operates in two different modes, depending on the 
type of the eventual control point (geodetic or relative). For each candidate 
geodetic control point, TCL interactively displays the associated CPN to an 
operator. The operator views the CPN along with the corresponding map marked 
with the control point location, through a zoom transfer scope. The operator 
transfers the control point location marked on the mp to the CPN image 
display. The operator interacts with TCL in this fashion to designate control 
point locations for an interval related data set. TCL then filters the 
control point locations for the data set to reject outlier points, extracts 
chips and auto— correlates them to determine their suitability for 
registration, and generates requests to update TM control point library 
entries for the original candidate control points. The update request either 
enters the designated control point chip into the library, or specifies a 
reject code (e.g., poor suitability). 

For each candidate relative control point, TCL calculates the location of the 
relative control point in the control point neighborhood, and interactively 
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displays the associated CPN to an operator. The registration control point 
chip is indicated by a visible box on the display. The operator may eiecL to 
accept or reject the chip, or may move the registration control point. If the 
operator accepts the chip, TCL performs processing similar to that described 
above to include the chip in the library. If the operator rejects the chip, 
TCL specifies a reject code in the update request (similar to above). If the 
operator moves the registration control point, TCL continues as above, from 
the point where the chip is indicated by a visible box on the display. 

6.5.1 HARDWARE DEVELOPMENT 

The system and image disks are DEC RP06, 176 Mbyte, 806 Kbyte/sec disk 

drives. There are three system and ten image disks per string. 

The host computer is a VAX 11/780 with five megabytes of main memory, eight 
massbusses and a floating point accelerator. 

The computer compatible tapes are standard 9-track tapes with 1600/6250 bpi 
densities and record speeds of 125 ips. 

The Goodyear laser beam recorder records images on 241 mm film at a rate of up 
to 2 Mpixels/sec. Photo IX shows the laser beam recorder. 

The Dicomed 70 mm film recorder converts digitally encoded TM data to high 
resolution (70 mm) photographic film. 

The TIPS system uses Comtal 512 x 512 pixel displays. These displays are used 
to verify system performance, examine image quality, assess cloud cover and 
select and designate control points. 

The SPDI accepts formatted serial data from the playback of high density 
tapes, performs frame synchronization on the data, and strips out and 
reformats this data into parallel words for transfer to the VAX. 
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The DSM inputs TM data in sensor format and performs data stream 
synchronization, data extraction and data quality monitoring. The DSM uuLpuls 
synchronized image, scah and quality data. 

The DFP inputs synchronized unprocessed TM scan data from the DSM and performs 
high speed pixel oriented processing and formatting functions. Partially 
decommutated scan data is output to the FFP while histograms are output to the 
VAX 11/780 or radiometric lookup tables are received from the VAX 11/780. 

The FFP is a high speed pipelined data processor used for data decommutation, 
correlation and geometric correction. In the data decommutation mode the FFP 
inputs partially decommutated scan data from the DFP and outputs fully 
decommutated data to the PSDO. In the correction mode the FFP inputs 
uncorrected control point neighborhoods and fully corrected control point 
chips from the VAX and outputs the correlation surface. In the geometric 
correction mode the FFP inputs uncorrected data and outputs geometrically 
corrected data. 

The PSDO accepts 32 bit parallel data from the FFP, reformats the data into 
major and minor frames and outputs a formatted serial bit stream to be 
recorded upon high density tapes. 

The matrix switch inputs digital data from the PSDO TM simulator on HDDRs and 
outputs digital data to the SPDI, DSM or an HDDR. 

The HDDRs are 28-track 33 Kbpi high density recorders used for inputting and 
outputting image data. The bit rates used in TIPS range from 2.8 Mbps to 
42.453 Mbps. 

6.5.2 SOFTWARE DEVELOPMENT 

The TIPS software structure shown in Figure 6.5-3 logically grouped functions 
and allowed for separate software development teams. The bulk of the TIPS 
software was written in Fortran. It consisted of approximately 268,000 lines 
of code. 
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Figure 6.5-3. TIPS Software Structure 
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software, developed by GE, vendor-supplied software, and system software, 
developed by GE to support non-standard peripheral devices. 


Additionally, parameter files were designed and used to supply values of time 
variant and invariant constants. 


6. 5. 2.1 Applications Software 


6. 5. 2. 1.1 TM Control and Communication 

For each major TIPS function, a number of controlling functions are required 
that are identical. To reduce software redundancy, most of these operations 
are removed from the TIPS functions of which they are a part and are allocated 
to a single package called the TM control and communication (TCC) package. A 
copy of the TCC package software executes on each TIPS string. Each copy 
executes independently, with no interface with the other copies. The TCC 
fulfills three classes of requirements. These requirements can be categorized 
as: MMF-T communication, string control, and work item handling. 

6. 5. 2. 1.2 TM Payload Correction Subsystem 

The PCS processes telemetry data to produce geometric correction functions 
that correct for systematic errors in the imagery. This process is performed 
on the DEC 2060. It involves the smoothing, validating and propagating of 
both the attitude and ephemeris data followed by the generation of systematic 
correction data. 

6. 5. 2. 1.3 TM Archive Product Generation 

The TM archive product generation (TAG) software performs the function of 
ingesting raw TM imagery intervals from an HDT-RT through the DSM/DFP/FFP, and 
outputting radiometrically corrected imagery to an HDT-AT through the PSDO. 
The TAG software performs its function based on a TAG work order received from 
TCC. Secondary functions of the TAG software provide for display of the 
Imagery during processing, generation of geometric/geodetic correction data, 
maintenance of quality indicators, subsampling of imagery for 70 mm film 
production, and manual and automatic cloud cover assessment of ingested scenes. 
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6. 5. 2. 1.4 TM Initial Product Generation 


The TM initial product generation (TIG; sottware pertorms the function or 
ingesting radiometrically corrected imagery in BIL format and its 
corresponding geodetic correction data on an HDT-AT through the SPDI, and 
outputting geodetically corrected imagery in BSQ format to an HDT-PT through 
the PSDO. The TIG software performs its function based on a TIG work order 
received from the TCC. TIG provides for display of the processed imagery 
during pipeline operation and maintenance of quality indicators. 

6. 5. 2. 1.5 TM Final Product Generation 

The TM final product generation (TFG) software provides for generation of end 
user products from either an HDT-AT or an HDT-PT. Final products are provided 
for a requested scene as either CCTs or 241mm film. The TFG software performs 
its function based on a TFG work order received from the TCC. The high 
density tapes are ingested under software control through the SPDI and output 
to either a CCT or the Laser Beam Recorder (LBR) for film output. TFG 
provides for display of imagery during processing and maintenance of quality 
indicators. 

6. 5. 2.1. 6 TM Control Point Library Build 

The TM control point library build (TCL) software provides for ingest of 
imagery from an HDT-PT, extraction of control point neighborhoods (CPN) and 
operator designation of candidate geodetic control points within the 
neighborhoods. Control point chips are extracted from the CPNs for inclusion 
in the control point library used for geodetic correction computations in 
TAG. The TCL also provides for digitization of candidate control points using 
a reference map to specify known locations in terms of latitude and longitude 
around the desired control point for subsequent selection of candidate CPN 
imagery extraction areas. 

6. 5. 2. 1.7 TM Quality Assurance Film Generation 

The TM quality assurance film generation (TQF) package produces 70 mm latent 
film images from selected bands of imagery for each scene recorded on an HDT 
AT during TAG. 
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6.5.2. 1.8 TM Data Quality Assurance 

TM data quality assurance (TDQ) software permits post-product quality checks. 
TDQ provides for format checks, dumps and displays of reingested HDT and CCT 
products. Quality reports summarize the results of the quality check(s) 
performed. 

6. 5. 2. 1.9 TIPS Utility Library 

The TIPS utility library contains software that performs functions common to 
many parts of TIPS. 

6. 5. 2.2 Purchased Sof tware 

This paragraph describes the pieces of software that were procured from 
outside sources to support the development of TIPS. This software was 
supplied by two sources: 

a. Digital Equipment Corporation (DEC) 

b. General Electric, Electronic Systems Division (Syracuse). 

Digital Equipment Corporation Supplied Software 

Three major packages of software were purchased from DEC to support TIPS. 
They are : 

a. VAX/VMS Operating System, including all of the associated support 
software. 

b. The Fortran-IV Plus compiler, along with all of the associated 
library functions. 

c. Decnet communications software. 

General Electric, Electronic Systems Division Supplied Software 
One major package was acquired from the General Electric Company Electronic 
Systems Division. This package consists of support software for the FFP. The 
components of this software are: 

a. Host Computer Software for the PDP-11/70 

b. DDP Resident Software 

c. System Control Terminal Software. 
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6. 5. 2. 3 System Support Software 

Software programs not connected with specific application packages are 
developed to control special designed hardware peripherals used in the TIPS 
strings. Associated with each driver is a program to exercise the driver and 
the hardware. The exerciser is not designed for hardware diagnostics, 
although in some instances it may be of limited use in this area. 

Photo X is a sample of the finished 241 mm product. 
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This section traces the history and evolution of the Transportable Ground 
Station (TGS) from the proposal stage through to its current configuration. 
Its overall performance is evaluated and, in paragraph 6.11.2, the lessons 
learned from its implementation are identified. 

6.6.1 FUNCTION 

The Landsat-D Transportable Ground Station, as specified by the RFP and 
defined in the General Electric Technical Proposal, is a receive only system. 
It is capable of acquiring and tracking the Landsat-D series spacecraft and 
receiving the following spacecraft signals: X-band wideband thematic mapper 

(TM) and multispectral scanner (MSS) data, S-band wideband MSS data, and 
S-band narrowband telemetry data. The TGS demodulates and bit synchronizes 
the received data, and retransmits the data via high speed modems for further 
processing. 

As originally conceived, the TGS function was to evaluate the quality and 
performance of the Landsat-D series spacecraft direct broadcast links, which 
were intended primarily for foreign ground station use. TGS also was to serve 
as a secondary data source of eastern U.S. coverage while installed at the 
GSFC site. The prime data link for the U.S. data processing system was the 
Landsat to TDRSS K-band link, TDRSS to White Sands, White Sands to NASA GSFC 
via Domsat link. The TGS was designed to be transportable to allow the system 
to be moved, after its initial performance evaluation function was completed, 
to selected remote sites where special data coverage requirements might exist, 
or which were in the zone of exclusion of the Landsat/TDRSS system 
combination. For this purpose, the TGS was designed to be transportable by 
C-141 type aircraft for installation at a previously prepared site within 
twenty working days. The requirement was for the system to be capable of 
disassembly and relocation a minimum of five times within a five year period 
without major overhaul, modification or performance degradation. 

The system proposed consisted of a 10-meter antenna subsystem, an electronics 
van subsystem, and a boresight test antenna subsystem. Site preparations 


103 


0994A 


WU1. VCJf y tl 


included a steel reinforced rnnrrpf-p foundation, cite 
trailer pad, cableways, electrical power and water supply. 

The TGS has become, in fact, the primary data acquisition source for Landsat 4 
and* 5 coverage of the eastern United States, and for the first year after the 
launch of Landsat 4, the only U.S. source of TM data. It can receive direct 
Landsat signals out to 3000 kilometers. 

6.6.2 SYSTEM CONFIGURATION 

The TGS is composed of three subsystems: the 10- meter antenna subsystem, the 
electronics van subsystem and the boresight subsystem. Figure 6.6-1 is a 
block diagram of the TGS. 

The 10-meter antenna subsystem includes an elevation over azimuth tracking 
pedestal; a Cassegrain antenna configuration consisting of a 10-meter 
parabolic reflector, a 60-inch hyperboloid subreflector, a dual quad X- and 
S-band feed assembly, monopulse comparators, monoscan converters, feed 
filters, parametric amplifiers, dual channel down-coverters, and test signal 
injection networks; and an antenna base extension including drive power 
amplifiers, additional electronics, and an azimuth axis tilt mechanism located 
at the base extension to pedestal interface. Figure 6.6-2 provides additional 
details of the antenna configuration. 

The electronics van subsystem is a 33-foot commercial air ride trailer that 
contains the receivers, demodulators, bit synchronizers, data link cable 
modulators; antenna control servo control unit, and computer; time code 
receiver and generator; and system test equipment. In addition, the van has 
expansion space for four additional racks of equipment. The van subsystem 
includes heating, air conditioning and lighting equipment. Figure 6.6-3 is a 
floor plan of the van. 

The boresight subsystem consists of an X-band antenna and an S-band antenna, 
both 4 feet in diameter, antenna positioners, a signal source, controller and 
remote control unit. This equipment provides the capability to checkout. 
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Figure 6, 6-1. Transportable Ground Station Block Diagram 
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Figure 6.6-2. TGS 10-Meter Antenna 




ad lust and verify the performance of the 10—meter antenna subsystem tracking 
function. 

Specifications for the performance requirements and for the system integration 
of -the TGS were performed by General Electric. The hardware design and 
fabrication were performed by Scientific Atlanta, Inc., (SA) under subcontract 
to GE. GE also provided the antenna pointing software with computer and 
related equipment. Installation and checkout of the system at GSFC was 
performed by SA and GE. Site preparations were provided by the GSFC 
Facilities Engineering Division and their subcontractors, based upon facility 
requirements established by GE. The bo resight antennas and signal source 
equipment were installed on an existing NTTF tower. 

6.6.3 IMPLEMENTATION 

The delivered system closely matched the proposed design due to the experience 
of the GE - SA team with similar previous projects. Some of the more notable 
differences are described in the following paragraphs. 

The electronics van length was increased from the proposed 25 feet to 33 
feet. This increase in size of the trailer provided additional space required 
for test equipment, the antenna control computer and terminal, parts and 
equipment storage, telex machine, and allowed expansion room for future 
equipment such as tape recorders. 

A programmable data formatter (PDF) was added to the TGS in response to 
Contract Change Notice 86. The PDF provides capability to transmit spacecraft 
telemetry and payload correction data via a 56-kilobit modem through Nascom to 
the CSF . The original plan was that NTTF telemetry would be used for data 
processing and consequently there was no need for the TGS telemetry data at 
the GSFC location other than for performance monitoring. The TGS provides a 
greater coverage circle than that available to the NTTF antenna due to less 
site masking. This resulted in TM scenes for which payload correction data 
was not locally available. The addition of the PDF simplified data processing 
by providing telemetry data for all scene data collected by the TGS. 
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~ four "■channel strip sh»rt recorder vss added lu Lite TGS LesL equipment 
complement In response to Contract Change Notice 85. This change allows 
simultaneous recording of S-band telemetry, S-band wideband data, and X-band 
receiver AGC signals for operational performance monitoring as well as 
additional system servo test capability. 

A number of enhancements were added to the antenna pointing software during 
the design and checkout phase. These include servo tests, time code generator 
interface tests, automatic prepass positioning of the antenna to its center 
zero, and prepass warning message, to name a few. 

6.6.4 PERFORMANCE 

Preliminary acceptance test of the TGS was completed at SA on 26 March 1981. 
The system was installed at GSFC during April 1981, 15 months in advance of 
the launch of Landsat 4. The installation went smoothly with the exception of 
the antenna foundation problems noted later in paragraph 6.11.2. During this 
period, the system was operated with the Landsat 2 and 3 spacecraft. Results 
of testing and operation verified that all required performance specifications 
were met or exceeded. The availability of the TGS well in advance of the 
spacecraft launch permitted extensive checkout of the system and resolution of 
minor system operational problems, in addition to weeding out early life part 
failures. 

The azimuth axis tilt was set to a predetermined value after installation of 
the system. The transformation of pedestal coordinates to true coordinates 
was verified to be accurate using the boresight position. Sun track and 
satellite track data. Prior to the launch of Landsat 4, the tilt was 

readjusted to its current value when the spacecraft ground tracks were more 
accurately defined. Azimuth axis tilt to solve the "keyhole problem" of 
elevation over azimuth tracking antennas was first used for the TGS antenna. 
Essentially, the tilt offsets the keyhole (the zenith circle through which the 
antenna cannot achieve sufficient acceleration and velocity to maintain the 
spacecraft within the antenna beamwidth) to a position that is between the 
satellite orbit paths. The fixed offset is an excellent solution for the 


109 


0994A 


Landsat application as the satellite nrhit-e are accurately maintained and the 
TGS was to be dedicated to tracking of the Landsat series of spacecraft. A 
variation of this design now uses a motorized tilt mechanism that allows the 
tilt angle to be adjusted between passes. This approach, based on the TGS 
design, is applicable to antennas that must track a variety of spacecraft. In 
addition to solving the X-band keyhole problem, the azimuth axis tilt 
eliminated the need for a zenith pass programmer, which was the technique 
previously used to solve the problem at the wider beamwidth of S-band. 

Another new design first used on the TGS was the 3- phase, servo power 
amplifiers. This design was undertaken to eliminate unbalance in the system 
a.c. power requirements. In addition to improving a.c. loading and 

regulation, the new design provided greater torque output to the elevation and 
azimuth drives. 

The wideband data link modems designed to transmit TM and MSS data to the 
DRRTS in Building 28 exceed the system performance requirement error rate of 
less than one part in 10^. 

The antenna pointing software was specifically designed for the TGS 
application. Antenna pointing information is calculated by the program prior 
to the spacecraft pass based upon the improved inter-range vector (I^RV) 
data entered by the operator. The program determines all crossings within the 
station acquisition circle, and calculates the pointing angles in 200 
millisecond increments for the selected number of passes. It determines AOS, 
LOS and highest elevation angle for each of the passes, and schedules passes 
for acquisition based upon the operator's instructions. Computation and 
scheduling may be performed for as many as four different satellites. When 
enabled, the computer, at the appropriate times, automatically positions the 
antenna at the anticipated AOS position, and then steps along the predicted 
track until acquisition and autotrack are achieved. The program continues to 
run; if autotrack is lost for any reason, the system reverts to program track 
in an attempt to maintain data reception, and returns to autotrack if the 
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tracking signal is re-acquired . After LOS the antenna is automatically 

returned to stow position and the next scheduled pass is announced. This 

subsystem was thoroughly tested after installation of the system at GSFC. The 

quality of program track data was compared to autotrack data. Program track 

2 

met -the design goals, providing the I RV data was current. 

Tests performed with both the Landsat 4 and the Landsat 5 spacecraft have 
demonstrated Flight Segment to Ground Segment bit error rates of less than one 
part in 10^ at antenna elevation angles as low as two degrees, exceeding 
system requirements. 
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6.7 GROUND SEGMENT INTEGRATION AND VERIFICATION 


The Landsat Ground Segment followed a standard methodology for integration and 
verification that differed very little from that proposed. It included the 
concept and schedule of Build tests. Stage tests. Facility tests. Ground 
Segment tests and Operational Readiness tests. 

Although each facility (MMF, CSF, DRRTS, MIPS and TIPS) had common names for 
these series of tests, in practice each facility organized its test team and 
its methodology somewhat differently. Build tests were defined, planned and 
conducted by the Software Engineering organization as a means to demonstrate 
their progress. Stage and Facility tests were conducted by independent test 
teams. The Ground Segment Integrated tests and Operational Readiness tests 
were led by different managers. Quality Assurance checks were imposed at the 
Stage test level. Each test required a written plan, a written procedure and 
a written report. Tests beyond Builds were required to be approved by the 
Engineering Review Board before beginning and after completing. This step 
instilled a Ground Segment-wide discipline to the conduct of tests. 

The next five sections discuss integration and verification activities within 
each facility, from Build testing through Facility tests. The last two 
sections address Ground Segment testing activities: (1) the Ground Segment 

Integrated Test (GSIT), and (2) the Operational Readiness Verification Tests 
(ORVTs) . 

As a result of the Landsat-D replan requirements, it became necessary to 
repeat tests that were already completed at the time of the rebaseline 
(mid-1980). Therefore, the summaries in this report give no date or results 
for some tests conducted before the rebaseline date. 

6.7.1 MISSION MANAGEMENT FACILITY (MMF) 

Progress of the development of the Mission Management Facility (MMF) was 
monitored and confirmed through a series of Build tests. Stage tests and a 
Facility test. Descriptions of these tests are summarized here. 
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6. 7. 1.1 MMF Build Tests 

HMF Build tests were conducted for: (1) Data Base Administration Subsystem 

(DAS), (2) Ground Segment Management Subsystem (GMS), (3) Flight Segment 
Management Subsystem (FMS) , and (4) Request Support Subsystem (RSS). A single 
Build test was conducted for the Interim TM Data System (ITDS). Dates and 
results of the MMF Build tests follow. 

DATA BASE ADMINISTRATION SUBSYSTEM (DAS) BUILD TESTS 

BUILD TEST DATE RESULTS 

DAS Build 1 Jan. 80 Demonstrated that the data base load 

processor properly initialized the static 
records of the data base. (Pre-re baseline) 

DAS Build 1A Dec. 80 Demonstrated that the data base load 

processor properly initialized the static 
records of the data base. (Repeat of DAS 
Build 1) 

DAS Build 2 May 81 Demonstrated the capability to support 

DECNET interface protocol and VT78 terminal 
complex. 

DAS Build 3 Jun. 81 Demonstrated common utility subroutines. 

DAS Build 4 Dec. 81 Demonstrated five capabilities: (1) area 

record summary report, (2) area set summary 
report, (3) area chain chaser for production 
and archive product areas, (4) main image 

bit verifier dump of main image area 
records, and (5) main image bit verifier 
comparator of main image area records to 
dump files. 

0993A 
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GROUND SEGMENT MANAGEMENT SUBSYSTEM (CMS) BUILD TESTS 


BUILD TEST DATE RESULTS 

GMS Build 1 Jan. 80 Demonstrated the capability of the MMF to 

schedule HDT-R to HDT-A processing and to 
account for that processing. 

(Pre-rebaseline) 

GMS Build 1A Apr. 81 This build was necessary to demonstrate the 

design changes that were implemented to 
comply with the Landsat-D replan 
requirements. (Repeat of GMS Build 1) 

GMS Build 2 Apr. 80 Demonstrated the capability of the MMF to 

schedule HDT-A to HDT-P processing. This 
build exercised automated cancellation and 
rework capabilities as well as the 
capability to account for successfully 

processed data. (Pre-rebaseline; TM only) 

GMS Build 3 Jul. 80 Demonstrated the capability of the MMF to 

schedule final product generation from one 

or more P-tapes (HDT-Ps). This build 
exercised automated cancellation, startover 
and rework capabilities, as well as the 
capability to account for successfully 

processed data. (Pre-rebaseline) 

GMS Build 3A May 81 This build was necessary to demonstrate the 

design changes that were implemented to 

comply with the Landsat-D replan 

requirements. Demonstrated the capability 
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of the MMF to support final product film 
generation from HDT-A/CCT-P tapes. (Repeat 
of GMS Build 3) 

GMS Build 4 Jul. 81 Demonstrated the capability to support final 

product CCT generation from HDT-A tapes. 

GMS Build 5 Oct. 81 Demonstrated the capability to support 

Control Point Library build activities. 

GMS Build 6 Aug. 81 Demonstrated the capability to support 

shipping of products, as well as DECNET 
transfer. 

GMS Build 7 Nov. 81 Demonstrated the capability of the MMF to 

support product tracking, product assessment 
entry, inventory tape generation and 
operational tasks. 

GMS Build 8 Sep. 81 Demonstrated the capability of the MMF to 

support product validation. 

GMS Build 9 Jun. 81 Demonstrated the capability of the MMF to 

request regeneration of HDT-A tapes for 
specified scenes, to request regeneration of 
products (CCT and film) for specified 
scenes, and to request copy and/or uplink to 
EDC of HDT-A tapes. 
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FLIGHT SEGMENT MANAGEMENT SUBSYSTEM (FMS) BUILD TESTS 


BUILD TEST DATE RESULTS 

FMS Build 1 Jun. 80 Demonstrated that the candidate request 

generation process properly generates a file 
of candidate requests for use by the Flight 
Scheduling Subsystem (FSS), and that the 
candidate request feedback accounting 
process can properly account for the 
candidate requests using feedback generated 
by the FSS. (Pre-re baseline) 

FMS Build 1A Mar. 81 Demonstrated that the candidate request 

generation process properly generates a file 
of candidate requests for use by the FSS, 
and that the candidate request feedback 
accounting process can properly account for 
the candidate requests using feedback 
generated by the FSS. 

FMS Build 2 Jul. 81 Demonstrated four capabilities: (1) The 

input file transfer program successfully 
processes the transfer of DECNET files from 
CSF to MMF, including the detection of 
duplicate deletion or transfer requests. 
(2) The MSS telemetry ingest process 
successfully processes MSS telemetry 
directory and data files. (3) The telemetry/ 
ephemeris packaging process successfully 
processes PCS Phase I output files. (4) The 
telemetry/ephemeris comparator process 
successfully examines the production area 
and the telemetry/ephemeris area of the MMF 
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FMS Build 3 

BUILD TEST 
RSS Build 1 
RSS Build 1A 

RSS Build 2 


RSS Build 2A 


data base to determine whether sufficient 
telemetry/ephemeris data exist to satisfy 
production requirements. 

Dec. 81 Demonstrated the capability to merge MSS and 

TM candidate requests and to segregate MSS 
and TM candidate request status. 


EQUEST SUPPORT SUBSYSTEM (RSS) BUILD TESTS 


DATE RESULTS 

Pre-re baseline . 

Nov. 81 Demonstrated the capability of the MMF to 

report on flight management activity, 
maintain and report on an inventory control 
system, and maintain and report on a problem 
defect tracking system. 

Feb. 80 Demonstrated three capabilities: (1) browse 

capability to access main image records, (2) 
Interactive Query Language (IQL) capability 
to access and report on main image data 
records, and (3) common parameter 
maintenance capabilities to access and 
modify records in the common parameter area 
of the MMF data base. 


May 81 Demonstrated the capability of the MMF for 

interactive inquiry of available Imagery and 
the generation of coverage catalogs for 
available imagery. 
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RSS Build 3 Feb. 81 Demonstrated the capability of the MMF to 

enter standing orders for acquisition 
products and retrospective orders for 
products. 

RSS Build 4 Dec. 81 Demonstrated the capability of the MMF to 

report on ground management activity, 
maintaining and extracting data from the 
spacecraft parameters World Reference System 
data base, and maintaining error code 
information in the MMF error-text data base. 

INTERIM TM DATA SYSTEM (ITDS) BUILD TEST 

BUILD TEST DATE RESULTS 

ITDS Build 1 Apr. 82 Demonstrated the capability to archive raw 

TM data and to generate systematic 
correction data (SCD) tapes for the Scrounge 
system. 

6.7. 1.2 MMF Stage Tests 

The MMF-M functions were integrated in five formal stage tests. Informal 
interfacility tests were performed on the CSF, MIPS and DRRTS to validate the 
interfaces. 

There was only one MMF-T formal stage test. However, that stage test used 
"live" data collected by the ITDS, as opposed to the mostly simulated data 
used for MMF-M stage testing. There were also informal interfacility tests 
with MMF-M and TIPS, which validated these interfaces. 
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STAGE TEST 
MMF Stage 1 


MMF Stage 2 


DATE DEMONSTRATED 

May 81 Scenario 1 - Initialized the data base. 

Scenario 2 - Demonstrated software to 

delineate user data from the order data. 

Scenario 3 - Demonstrated the capability to 
enter order information. 

Scenario 4 - Demonstrated the use of 

interactive input to change status of a user 
and/or order. 

Scenario 5 - Demonstrated the ability to 

generate candidate requests. 

Scenario 6 - Demonstrated the generation of 
candidate requests for mission planning. 

Scenario 7 - Demonstrated the accounting for 
candidate requests. 

Jun. 81 Scenario 1 - Data base initialization. 

Scenario 2 - User and order information tape 
processing. 

Scenario 3 - Candidate request generation. 

Scenario 4 - Candidate request feedback 

accounting. 
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Scenario 5 - Stage two data base 

initialization. 

Scenario 6 - HDT-R directory entry. 

Scenario 7 - HDT-R directory inversion. 

Scenario 8 - Process request generation for 
archive generation. 

Scenario 9 - Archive generation process 

request feedback. 

Scenario 10 - Archive item close out. 

Scenario 11 - Archive generation rework. 

MMF Stage 3 Sep. 81 Scenario 1 - Data base initialization for 

EROS Data Center (EDC) tape load. 

Scenario 2 - User and order information tape 
processing/DECNET protocol utilities. 

Scenario 3 - VT78 terminal complex support. 

Scenario 4 - Candidate request generation. 

Scenario 5 - Input file transfer/candidate 
request feedback. 

Scenario 6 - Tape backup for DECNET. 

Scenario 7 - Telemetry/ephemeris processing. 
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Scenario 8 - HDT-R directory entry. 

Scenario 9 - HDT-R directory inversion. 

Scenario 10 - Process request generation for 
archive generation. 

Scenario 11 - Archive generation process 
request . 

Scenario 12 - Archive item close out. 

Scenario 13 - Route data base management. 

Scenario 14 - Imagery browse. 

Scenario 15 - User data entry. 

Scenario 16 - User and order status 
modification. 

Scenario 17 - Standby order information 

entry (manual mode). 

Scenario 18 - Retrospective order entry. 

Scenario 19 - Final product process request. 

Scenario 20 - Final product film feedback. 

Scenario 21 - Archive regeneration request 
entry. 
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Scenario 22 - Quality assessment feedback.. 

Scenario 23 - Photo lab process request 

generation. 

Scenario 24 - Photo lab film feedback. 

Scenario 25 - Product regeneration request 
entry. 

Scenario 26 - EDC retrospective HDT copy 

uplink. 

Scenario 27 - Wrap-up (prints file and logs 
off). 

Scenario 1 - Initialization. 

Scenario 2 - User and order information 

processing/DECNET protocol utilities. 

Scenario 3 - Candidate request generation- 
scheduling activity. 

Scenario 4 - Operations log. 

Scenario 5 - Input file transfer/candidate 
request. 

Scenario 6 - Octal dump. 

Scenario 7 - Telemetry/ephemeris processing. 
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Scenario 8 - HDT-R directory entry. 

Scenario 9 - HDT-R directory inversion. 

Scenario 10 - Process request generation for 
archive generation. 

Scenario 11 - Archive generation process 
request feedback. 

Scenario 12 - Archive item close out. 

Scenario 13 - Route data base management . 

Scenario 14 - Imagery browse. 

Scenario 15 - User data entry. 

Scenario 16 - User and order status modify. 

Scenario 17 - Standing order information 
entry (manual mode). 

Scenario 18 - Retrospective order entry. 

Scenario 19 - Final product process request 
generation rework. 

Scenario 20 - Final product film feedback. 

Scenario 21 - Archive regeneration request 
entry. 
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Scenario 22 - Quality assessment feedback. 


Scenario 23 - Photo lab process request 

generation. 

Scenario 24 - Photo lab film feedback. 

Scenario 25 - Product regeneration request 
entry. 

Scenario 26 - EDC retrospective HDT copy 

uplink. 

Scenario 27 - Final product tape feedback 
(manual). 

Scenario 28 - MMFCC CCT process request 

generation. 

Scenario 29 - MMFCC CCT copy feedback. 

Scenario 30 - DRRTS process request 

generation. 

Scenario 31 - DRRTS uplink and copy feedback. 
Scenario 32 - Wrap-up. 

MMF Stage 5 Jan. 82 Management reports and tracking. 

MMF Stage 6 Nov. 82 Four objectives: 

(1) Created an integrated test environment 
from CMO controlled library. 

(2) End-to-end integration of MMF-T. 
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(3) Established a baseline for interface 
testing. 

(4) Use "live" ITDS data for testing. 


6. 7. 1.3 MMF Facility Tests 

The MMF Facility Test was conducted in February 1982 to verify MMF 
capabilities. 

6.7.2 CONTROL AND SIMULATION FACILITY (CSF) 

The Control and Simulation Facility (CSF) followed the master scheme for 
staged integration and verification, but added some unique tests not found in 
the other facilities. In early July 1981 (Program Directive No. 215), it was 
directed by the Program Office that a new series of tents be conducted. These 
major item verification tests (MIVTs) were to verify all requirements at the 
subsystem level. It was originally intended to do this verification in the 
stage tests, but early results from stage testing showed this not to be 
feasible due to schedule slips, the amount of formal control required and the 
staged subsystem implementation scheme. As a result, stage test objectives 
were concentrated on testing functionality of the incremental subsystem builds 
and MIVTs concentrated on requirements verification for completed subsystems. 

The CSF was involved in many external interfaces that required additional 
testing. These included the Flight Segment/Ground Segment Compatibility 
Tests, several interface tests, and an FOS Confidence Test. These tests will 
be discussed further under Facility testing. 

6. 7. 2.1 CSF Build Tests 

The builds were defined for DDR in early 1980, and several were completed, 
tested and verified prior to the rebaseline in late 1980. The post-rebaseline 
builds were defined to include the entire new baseline. A brief description 
of each build and the test date are listed below by subsystem: 
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BUILD 

TEST DATE 

DESCRIPTION 

TSIM-4 

Dec. 80 

Simulation support, real-time simulation. 

TSIM-4A 

Feb. 81 

Rerun of TSIM-4 with upgraded VMS (version 2.1) 

TSIM-5 

May 81 

Integration of Nascom and FOS into simulations. 

TSIM-5A 

Sep . 81 

GPS modeling. 

FOS-1 

Jan. 81 

Nascom, COIL. 

FOS-2 

Mar. 81 

Data base. 

FOS-3 

May 81 

Telemetry processing. 

FOS-4 

Jun. 81 

Operator control and display. 

FOS-5 

Aug . 81 

Command • 

FOS-6 

Nov. 81 

Communications control. 

FSS-2 

Mar. 81 

Uplink data generation. 

FSS-3 

May 81 

Scheduling support. 

FSS-4 

Aug . 81 

Acquisition analysis. 

FSS-5 

Jul. 81 

Mission scheduling. 

FSS-6 

Oct. 81 

Mission scheduling. 

FSS-7 

Dec. 82 

D-Prime, TDRSS. 
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PES-1 


Nov. 81 


Telemetry display. 


PES-2 

Jan . 82 

Spacecraft analysis. 

NCC-1 

Nov. 81 

Message routing. 

NCC-2 

Aug . 82 

Real-time message routing. 

NCC-3 

Sep . 82 

MPT integration. 

6. 7. 2. 2 CSF Stage Tests 


Each stage test was comprised of several builds from various subsystems, which 
together represented a major function of the CSF. An incremental baseline of 
control center functionality was thus built and exercised through the stage 
tests. The test date and a brief description of each stage follows: 

BUILD 

TEST DATE 

DESCRIPTION 

2 

Mar. 81 

Initial stage baseline procedures. 
TSIM telemetry generation. 

FOS telemetry processing. 

FSW baseline scenarios. 

3 

May 81 

Data base and MIT files. 
NIF/SU interface. 

COIL, OBC, uplink data tests. 
FOS performance testing. 

4 

Jul. 81 

Process TSIM telemetry and dump data. 


Scheduling support software. 
Performance measurement. 

COIL testing continued. 
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5 


Sep. 81 COIL stress testing. 

Real-time processing performance measurement. 
FSS reverification. 

PCD, STR data processing. 

6 Feb. 82 Mission scheduling. 

Acquisition accounting. 

FOS/TSIM continuous orbital operations. 
Performance measurement. 


7 

8 

9 


Feb. 82 Full CSF capabilities. 

Sep. 82 NCC message generation and processing. 

Real-time NCC operations. 

Dec. 82 D-prime. 


6. 7. 2. 3 CSF Ma.jor Item Verification Tests 

The major item verification tests (MIVTs) concentrated on subsystem 
requirements for verification instead of system functions. Other areas that 
were monitored during the MIVTs included: software as-built documentation, 
unit development folders, outstanding discrepancy reports (from unit, build 
and stage testing), and CMO baseline of the MIVT test items. The MIVTs, test 
dates and contents were: 


MIVT 


1 

2 


2A 


TEST DATE 
Sep . 81 
Nov. 81 

Nov. 81 


DESCRIPTION 

Nascom I/O scheduling support. 

Operator control and display. 

Telemetry processing. 

Repeat of MIVT 2 after problem correction. 
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3 


Jan. 82 


Test and simulation subsystem. 


4 Mar. 82 Flight scheduling. 

Network control center. 

5 Feb. 82 Performance evaluation. 

Command. 

Communication control. 
Network control. 

Support services. 


6.7. 2.4 CSF Facility Tests 

There were several facility-level tests conducted in the CSF prior to the 
launch of Landsat“D. They are listed below: 


Facility Test 

Mar. 82 

CSF Interfaces: 


CSF/TGS 

Aug. 81 

TGS/DRRTS 

Dec. 81 

MMF/CSF 

Nov. 81 

CSF/DRRTS 

Feb. 82 

Van Compatibility Tests 

Jan. 82 and May 82 

Network Data Flows 

Apr.-Jun. 82 

Network Launch Simulations 

Jun.-Jul. 82 

Launch/Early Orbit 

Jun. 82 

24-hour Scheduling Test 

Jun. 82 

CSF All Hands Launch Simulation 

Jul. 82 


The majority of these tests were related to launch readiness evaluations. The 
rest were verifications of interfaces within the Ground Segment. All of the 
tests were directed by I&T or Systems Engineering personnel and performed by 
the operations crew. The tests served both as verification and training 
exercises. All of the tests were concluded successfully; problems encountered 
were documented on PDRs and resolved before the next test. The Van 
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Compatibility Test was repeated four months later for several reasons: the 
spacecraft was available for a week prior to shipment to the West Coast, the 
CSF had been through several facility-level tests during that four-mounth 
period, the data base and procedures had matured considerably and were 
basically flight-ready. The second van test was very successful and bolstered 
our confidence. 

In parallel with this series of Facility tests in the CSF, the rest of the 
Ground Segment was going through Facility, Ground Segment and Operational 
Readiness testing. The CSF participation in these tests was kept to a minimum 
to allow the control center and crew to concentrate on launch readiness. Test 
data, processing of incoming interface data and points of contact were 
provided primarily by the I&T team members not directly involved in launch 
readiness. These tests are further described later in this report. 


Facility tests conducted prior to the launch of Landsat-D Prime were: 
Facility Test Jan. 84 

FOS Confidence Test Nov. 83 

Van Compatibility Test Jan. 84 

Network Data Flows Jan. -Feb. 84 

Network Launch Simulations Feb. 84 

Launch/Early Orbit Feb. 84 

CSF All-hands Launch Simulation Feb. 84 


All of the tests were directed by GE Systems Engineering and performed by NOAA 
contractors, except for the Facility test, which was totally performed by the 
NOAA contractor. 

6.7.3 DATA RECEIVE, RECORD, TRANSMIT SYSTEM (DRRTS) 

Progress of the development of the Data Receive, Record, Transmit System 
(DRRTS) was monitored and confirmed through a series of Build tests. Stage 
tests, and a Facility test. Descriptions of these tests are summarized here. 
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6.7. 3.1 DRRTS Build Tests 

The DRRTS had three software Build tests defined. These tests were: 

BUILD TEST TEST DATE RESULTS 

Build DRRTS 1 Sep. 81 Demonstrated the ability to control the 

high density digital tape records. 

Build DRRTS 2 Nov. 81 Demonstrated the full data receive, record 

and transmit capabilities, including 

directory generation for MSS data. 

Build DRRTS 3 May 82 Demonstrated the full data receive, record 

and transmit capabilities including 

directory generation for TM data. 

The first and second DRRTS Build tests were the foundation for the first Stage 
test and then an MSS Facility test, led by the DRRTS System Engineer, in 
January 1981. The third Build test was conducted along with the second Stage 
test (a demonstration of TM capabilities). 

The DRRTS testing was highly successful due to the following factors: (1) 

well-planned tests, (2) availability of test data from simulators or test 
tapes, (3) prompt elimination of hardware and software defects, (4) special 

attention paid to hardware and software configuration control, and (5) close 
cooperation between the testers, the hardware maintenance staff and software 
engineering. 

6. 7. 3. 2 DRRTS Stage Tests 

There were two DRRTS Stage tests. Stage test one was conducted in January 
1981, and Stage test two, a demonstration of TM capabilities, was conducted in 
May 1982. 
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6.7. 3.3 DRRTS Facility Test 

The DRRTS FAcility test was Included In the Ground Segment Integration Test in 
March and April 1982. 

6.7.4 MSS IMAGE PROCESSING SYSTEM (MIPS) 

Development of the MSS Image Processing System (MIPS) was monitored and 
confirmed through Build tests. Stage tests, and a Facility test. A summary of 
these tests is contained here. 

6. 7. 4.1 MIPS Build Tests 

The MSS Image Processing System (MIPS) Build tests were conducted for: (1) 

MSS Archive Generation (MAG), (2) Performance Evaluation Product Generation 
(PEPG) - A, (3) Performance Evaluation Product Generation (PEPG) - P, (4) 
Control Point Library Build, (5) Payload Correction Subsystem, and (6) Manual 
Cloud Cover Assessment (MCCA). 


MSS ARCHIVE GENERATION (MAG) 

Four Build tests were related to MSS Archive Generation (MAG): 


BUILD TEST TEST DATE 


RESULTS 


Build MAG 1 Jul. 81 Demonstrated the completeness and accuracy 

of calculation phase algorithms and showed 
what an operator experiences during the 
production of an MSS HDT-A tape. 

Build MAG 2 Aug. 81 Demonstrated the equivalence of AP-180V 

calculation phase software to VAX software 
demonstrated in Build 1 and demonstrated 
the correctness of output phase software by 
producing an output computer compatible 
tape. 
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Build MAG 3 Nov. 81 Demonstrated the entire MAG package in a 

standalone fashion Including ingest, 
calculation and output processing. 

Build MAG 4 Nov. 81 Demonstrated the interface of the MAG-3 

build with the manual cloud cover 
assessment and quality assurance film 
generation to show MSS archive generation 
processing in a realistic environment. 

Builds MAG 3 and 4 were combined into one 
test. 

PERFORMANCE EVALUATION PRODUCT GENERATION (PEPG) - A 

Two Build tests were conducted in relation to the Performance Evaluation 
Product Generation (PEPG) - A: 


BUILD 

TEST 

DATE 



RESULTS 



Build 

PEPG 1 

Jul. 

81 

Provided 

a minimal 

operational evaluation 





product 

generation 

capability that 

served 





as the 

foundation 

for subsequent 

Build 





tests. 




Build 

PEPG 2 

Sep. 

81 

Demonstrated full 

capability to 

process 


partially corrected scene data including 
activation and control by the CCP. 


PERFORMANCE EVALUATION PRODUCT GENERATION (PEPG) - P 
BUILD TEST DATE RESULTS 

Build PEPG 3 Jan. 82 Demonstrated the fully operational PEPG 

system. 
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CONTROL POINT LIBRARY BUILD (CPLB) 


There were three Build tests associated with the Control Point Library Build: 

BUILD TEST DATE RESULTS 

Build CPLB 1 Sep. 81 Demonstrated the ability to identify 

latitude and longitude of candidate control 
points and the ability to analyze control 
point neighborhoods that fail to correlate. 

Build CPLB 2 Jan. 82 Demonstrated the ability to correlate 

control points using Comtal and Zoom 
transfer scope, and extract and 
geometrically correct a candidate control 
point neighborhood from A-tape data. 

Build CPLB 3 Jan. 82 Demonstrated the ability of the control 

point library build software to interface 
with the MIPS control and communication 
package. 

Builds CPLB 2 and 3 were combined into one 
Build test. 

PAYLOAD CORRECTION SUBSYSTEM (PCS) 

BUILD TEST DATE RESULTS 

Build PCS 1 Oct. 81 Demonstrated the ability to generate 

systematic correction data from 

pre-smoothed attitude, ephemeris and 
telemetry data. 
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Build PCS 2 


Jan. 82 


Demonstrated the ability to generate 
systematic correction data after processing 
spacecraft attitude, ephemeris and 
telemetry data. 

MANUAL CLOUD COVER ASSESSMENT (MCCA) 

BUILD TEST DATE RESULTS 

Build MCCA 1 May 81 Demonstrated; (1) display of menu, 

(2) acquisition of operator commands, 

(3) interface with control and 
communication package, (4) interface with 
the Logger utility, (5) generation of a 
summary display of scenes in the current 
work order, (6) application of radiometric 
corrections to subsampled image data, (7) 
display of radiometrically corrected image 
data and annotation on Comtal display, (8) 
acquisition from the operator of cloud 
cover scores for each quadrant of each 
scene in a work order, and (9) generation 
of a processing summary report. 

6. 7. 4. 2 MIPS Stage Tests 

MIPS testing included five Stage tests. 


STAGE TEST 

DATE 


DEMONSTRATED 

MIPS Stage 1 

Nov. 81 

Scenario 
of a MIPS 

1 - Initialization (cold startup 
string). 
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Scenario 2 - Generation of CCT-AM from 

HDT-AM (production mode). 

Scenario 3 - Generation of summaries, 

dumps, performance evaluation (PE) reports 
and Comtal displays. 

Scenario 4 - Comtal scene displays. 

Scenario 5 - Interactive summaries, dumps 
and PE report generation. 

Scenario 6 - Ingest of CCT-AM. 

Scenario 7 - Generation of CCT-AM from 

HDT-AM (engineering mode). 

Scenario 8 - Ingest of HDT-AM. 

Scenario 9 - Test pattern generation. 

Scenario 10 - Termination. 

MIPS Stage 2 Jan. 82 Scenario 1 - String startup test. 

Scenario 2 - Line test. 

Scenario 3 - Control and communication test. 

Scenario 4 - Timing, concurrent operation 
and disk capacity test. 

Scenario 5 - Radiometric correction test. 
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Scenario 6 - Control point correlation and 
SCDG/GCDG test. 

MIPS Stage 3 Feb. 82 Scenario 1 - Scene selection and candidate 

GCP selection. 

Scenario 2 - Candidate GCP digitization. 

Scenario 3 - Control point generation. 

Scenario A - Relative control point 
generation. 

Scenario 5 - Control point display. 

Scenario 6 - Landsat 2/3 GCP conversion and 
termination. 

MIPS Stage A Jan. 82 Scenario 1 - Initialization. 

Scenario 2 - Normal payload correction 

system (PCS) processing. 

Scenario 3 - Anomalous data processing. 

Scenario A - Error recovery. 

Scenario 3 - Parallel operation. 

MIPS Stage 5 Apr. 82 Scenario 1 - Initialization. 

Scenario 2 - Generation of CCT-PM from 

HDT-AM. 
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Scenario 3 - ingest ot ccx-m. 

Scenario 4 - Comtal scene display. 

Scenario 5 - Interactive summaries, dumps, 
and performance evaluation (PE) reports. 

Scenario 6 - Ingest of CCT-AM. 

Scenario 7 - Test pattern generation. 

Scenario 8 - Termination. 


6.7. 4.3 MIPS Facility Test 

The MIPS Facility Test was conducted along with the Ground Segment Integration 
Test. 


6.7.5 TM IMAGE PROCESSING SYSTEM (TIPS) 

Development of the TM Image Processing System (TIPS) was monitored and 
confirmed through Build tests. Stage tests, and a Facility test. A summary of 
these tests is contained here. 

6. 7. 5.1 TIPS Build Tests 

TIPS Build tests were conducted for: (1) TM archive generation (TAG), (2) TM 
data quality assessment (TDQ), (3) TM initial product generation (TIG), (4) TM 
final product generation (TFG), (5) TM control point library build (TCL), (6) 
TM payload correction system (TPC), and (7) quality assurance film build (TQF). 

TIPS ARCHIVE GENERATION (TAG) BUILD TESTS 
BUILD TEST DATE RESULTS 

TAG Build 1 Oct. 82 Demonstrated the Pass 2 archive generation 

capability with image data output to disk 
using the Parallel to Serial Data Output 
Device (PSDO) simulator. 
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TAG Build 2 Oct. 82 Demonstrated correction data processing 

capability, including radiometric 

correction, correlation and auxiliary data 
generation. 

TAG Build 3 Mar. 83 Demonstrated full TM HDT-AT generation 

capability, including TAG Build 1 and TAG 
Build 2, Pass 1 archive generation and 
manual cloud cover assessment. 

TIPS DATA QUALITY ASSESSMENT (TDQ) BUILD TESTS 


BUILD TEST 

DATE 

RESULTS 

TDQ Build 1 

Mar. 83 

Demonstrated a minimal operational system. 

TDQ Build 2 

Apr. 83 

Demonstrated full high density digital tape 



capabilities . 

TDQ Build 3 

Apr. 83 

Demonstrated full data quality assessment 


capabilities . 

TIPS INITIAL PRODUCT GENERATION (TIG) BUILD TESTS 

BUILD TEST DATE RESULTS 

TIG Build 1 Oct. 82 Demonstrated the geometric correction 

capability. 

TIG Build 2 Mar. 83 Demonstrated full initial product 

generation capability, generating high 
density digital product (HDT-P) tapes from 
high density digital archival (HDT-A) tapes. 

0993A 
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TIPS FINAL PRODUCT GENERATION (TFG) BUILD TEST 


BUILD TEST DATE RESULTS 

TFG Build 1 Mar. 83 Demonstrated the full capabilities of the 

final product generation package. 

TIPS CONTROL POINT LIBRARY (TCL) BUILD TEST 

BUILD TEST DATE RESULTS 

TCL Build 1 Apr. 83 Demonstrated the full capabilities of the 

control point library build package. 

TIPS PAYLOAD CORRECTION SYSTEM (TPC) BUILD TEST 

BUILD TEST DATE RESULTS 

TPC Build 1 Oct. 82 Demonstrated the full capabilities of the 

TIPS payload correction system package. 

TIPS QUALITY ASSURANCE FILM (TQF) BUILD TEST 

BUILD TEST DATE RESULTS 

TQF Build 1 Apr. 83 Demonstrated the full capabilities of the 

quality assurance film generation package. 

6. 7. 5. 2 TIPS Stage Tests 

There were four Stage tests conducted to verify that requirements of the TIPS 
Specification, GES 10081, were met. Stage tests were scheduled to be 
conducted in three phases: (1) test data generation, (2) test plan and 
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procedure generation, and (3) actual testing, analysis and presentation of 
results. A listing of these four tests follows. 

STAGE TEST DATE RESULTS 

TIPS Stage 1 Oct. 82 Demonstrated operation of the payload 

correction system (PCS) to process TM 
payload correction data (PCD-T) and to 
produce systematic correction data. 

TIPS Stage 2 Mar. 83 Demonstrated the generation of archival 

high density digital tape (HDT-A) by 
processing TM raw video data contained on 
an HDT-R tape to partially corrected data 
on both an HDT-A tape and 70 mm film. 

TIPS Stage 3 Mar. 83 Demonstrated the generation of initial 

product high density digital tape (HDT-P) 

by processing TM archival data contained on 
an HDT-A tape to geometrically corrected 
data on an HDT-P tape. 

TIPS Stage 4 Apr. 83 Demonstrated the capability to generate 

CCTs by scene quadrants from HDT-A tapes 
and HDT-P tapes and generating 241 mm film 
from HDT-P tape data. This test also 
demonstrated the creation of new control 
points from recently acquired Landsat-D 

imagery and operation of the control point 
library build process. 

6. 7. 5. 3 TIPS Facility Test 

The TIPS was released to the Ground Segment as one facility. The Facility 
test was completed in June 1983. The TIPS Facility test verified requirements 
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that had been deferred from or failed in the tour stage tests. Requirements 
from the Ground Segment Specification, GES 10045, were verified. 

6.7.6 GROUND SEGMENT INTEGRATION TEST (GSIT) 

The Ground Segment Integration Tests (GSIT) were conducted during March and 
April 1982. The primary objectives of the GSIT were: (1) to demonstrate the 
Ground Segment as an integrated functional entity and to establish the GSIT 
baseline for future enhancements, and (2) verify Ground Segment requirements. 
Secondary objectives were: (1) to demonstrate the Ground Segment using 
operational scenarios in preparation for the operational readiness period, and 
(2) to maximize early M&O involvement at all levels to facilitate transition 
to the ORVP. 

A comprehensive series of integrated Ground Segment activities was structured 
to simulate a multiple-day operational scenario. Subjects included were: (1) 
user request processing, (2) Flight Segment planning and scheduling, (3) 
orbital operations and data acquisition, (4) image data acquisition and 
transmission, (5) product generation, quality assurance, and distribution, (6) 
mission data management, (7) inventory control and problem defect report (PDR) 
tracking, and (8) management control and reporting. 

6.7.7 OPERATIONAL READINESS VERIFICATION TEST (ORVT) 

The ORVT extended from April 1982 to July 1982. Key objectives for the ORVT 
were: (1) verify operational readiness of maintenance and operations, and (2) 
complete development, integration and validation of the Landsat-D launch 
baseline. The ORVT was conducted in three phases. 

The objective of Phase One was to demonstrate Ground Segment Release 2.0. 
Phase One was, in effect, a re-run of the GSIT with several modifications 
and/or additions. Telemetry was generated by TSIM. Operational CSF software 
generated all interface data items from CSF to MMF. The test exercised the 
interfaces between CSF and MMF in a semi -operational mode. 
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The objectives of the ORVT Phase Two test were to demonstrate an integrated 
Ground Segment with end-to-end data flows and to exercise internal operational 
interfaces. Operational requirements of TSIM were verified. Operational 
readiness of standard operating procedures and of M&O personnel was 
demonstrated. Phase Two consisted of two parts. The first part included 
activities associated with launch and early orbit activation tasks. The 
second part consisted of Ground Segment activities that exercised the OCC and 
DMS in an integrated end-to-end operational mode. The Flight Segment was 
represented by the TSIM. 

The objective of Phase Three was to demonstrate the operational readiness of 
the Ground Segment in a real-time mode of operation. MMF and CSF performed 
their scheduling functions. All external interfaces were tested. Phase Three 
was a full-up Ground Segment test with a duration of five days. 
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6.8 LANDSAT-D/D PRIME DESIGN ENHANCEMENTS 


6.8.1 MMF DESIGN ENHANCEMENTS 

As with any system that is developed over a period of years, the MMF was 
modified by design enhancements. Those enhancements that were implemented 
prior to the program rebaseline of mid-1980 are discussed in this paragraph; 
the remainder are discussed in paragraphs 6. 8. 1.1 and 6. 8. 1.2. It must be 
noted that the design enhancements to the MMF-M software were also carried 
over to the MMF-T software design. 

The major hardware enhancement in the MMF was a CPU/main memory upgrade to the 
DEC System 10. The model 1091 central processor was upgraded to become 
equivalent to that of a DEC System 20 Model 2050 and the main memory size was 
doubled. This paved the way for the DEC System 20 being the model line for 
the two MMF systems in the Ground Segment. 

6. 8. 1.1 MMF-M Design Enhancements 

The initially conceived control mechanism for the MMF-M software executables 
was that of hard-coded job control streams that invoked a series of programs 
in one "transaction.” This concept was replaced by a new control processor, 
the Menu, which allowed for "transaction" processing as well as for the 
execution of each individual program. The Menu was developed so that it would 
be very user friendly, taking the production control operator through the 
logical data flow paths by way of layered process selection screens. The Menu 
performed standard functions for each program (e.g., printing the summary 
reports) as well as allowing for command files to be tailored to the needs of 
the individual programs. The Menu also provided for the implementation of 
"run time switches" which replaced the use of data base parameters as a way of 
having the operator control certain run-time aspects of the program. This 
feature allowed, for example, the production control operator to run a given 
process in a selective mode (e.g., to expedite high priority data sets), or in 
a batch production mode. This particular feature was implemented because 
there was an overall design upgrade to the MMF-M software that required all 
processes to have the operator selection option. This option proved 


144 


099 3A 


invaluable during the initial operations phase, when problem data sets 
routinely encountered were bypassed via operator selection. 

Another major design enhancement to the MMF-M was in the area of the 
production control software. Scenes in the various steps of processing 
(archive generation, product dissemination, PEPG) were to be restatused after 
each processing step by the MMF-M application software. The status 
transitions were originally hard-coded in the application software. These 
status transitions were abstracted out of the software and embedded as data 
elements in the MMF-M processing route step data base area. This abstraction 
significantly simplified the product processing approach and was directly 
transferable to the MMF-T system, which dealt in a more complex product mix. 

Numerous software development/maintenance tools were developed or acquired 
during the MMF— M development era. Some of these tools became a part of the 
operational system in addition to benefiting the software development. The 
full screen file browse tool and full screen editor became tools for 
operational verification of process completion and for problem data set 
investigation/correction. An MMF-M cross-reference data base was developed to 
provide automated data base data dictionary generation, software module/data 
base element correlation, and software lines of code counts. 

6. 8. 1.2 MMF-T Design Enhancements 

In addition to the MMF-M design enhancements that were incorporated into the 
MMF-T design, there were numerous design modifications made to the MMF-T alone. 

In the hardware area, there were two major design enhancements. The mid-1980 
NASA D-100B specification required only 12 TM scenes per day be processed. In 
light of that requirement, GE selected a DEC System 2040 for the MMF-T host 
computer. As indications of the final system requirement of 100 1M scenes per 
day resurfaced, the plans for the DEC System 2040 were rapidly changed, and 
the order for a DEC 2040 was changed to a DEC 2060. This "on-paper” 
enhancement was advertised to increase the processing power of the MMF-T by a 
factor of three. 
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Through the development phase of the MMF-T system, the mass storage system was 
augmented to a total of 8 Model RP06 disk units, one of which was the 
switchable disk, used for MMF-M/MMF-T data transfer. An additional disk 
controller was added in order to distribute the mass storage demand, resulting 
in a balanced system of four disk units on each controller. 

The original MMF-T configuration had two Model TU77 tape drives, capable of 
recording at 800 or 1600 bpi. When the TM archiving subsystem began recording 
PCD and video tape directory data for 60-90 scenes per day, the need for 
higher density CCT tape drives became evident. Two model TU78 tape drives 

(1600 or 6250 bpi recording density) were added to the MMF-T configuration. 

The final hardware enhancement made to the MMF-T was to the DEC 2060 main 
memory. The 512K 36-bit words of M0S memory was removed and replaced with 

1024K 36-bit words of a newer model M0S memory. This main memory swap 

resulted in a noticeable performance improvement during periods of moderate to 
high system load. 

There were several design enhancements made to the MMF-T software system 
during the development period. One of the most complex software design 
enhancements was in the area of TIPS and PCS parameters maintenance. The 

parameters maintenance design allowed for temporal parameter changes, but not 
for absolute parameter changes. This meant that new parameter values could be 
installed so that processing of future scenes would use the new values, but 
processing of older scenes would not. This design was enhanced to allow for 
"retroactive” dates of applicability. The design enhancement also allowed for 
the retention of the previous parameter files, which would be marked as 
"inactive," for historical purposes. 

Since the TIPS and PCS parameters maintenance was being performed in a 
production support environment that was separated from the production data 
base, a "population" step was performed with each parameter installation. 
This step involved adding index records in the production data base for the 
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newly-generated parameter files ana copying che new paieaieLei files iuLo Lue 
production account. This manual process was automated with the final 
parameters maintenance design enhancement, known as the automated parameter 
population module. 

Two applications programs were added to the MMF-T data base maintenance area 
as design enhancements. The directory area maintenance utility, DBFILE, 

allowed operations personnel to manipulate the current index/delete index 
lists in the data base, which proved to be a very powerful and flexible 

capability. The production area status modification utility, DBSTAT, allowed 
operations personnel to restatus for reprocessing scenes failed by PCS, after 
corrective action had been taken. This utility also allowed for a more potent 
capability to alter the status of any scene in the production area. This 

capability, which was reserved for use by the data base administrator, was 
utilized in a housekeeping fashion periodically; e.g., to cancel bad data sets. 

One of the most beneficial design enhancements to the MMF-T was in the area of 
concurrent data base operations. Although no two data base updating programs 
were allowed to be run concurrently, a data base read-only program could 
theoretically run concurrently with a data base updating program. The 

drawback of the concurrent operation was that the data values being examined 
by the read-only program could, at the same time, be modified by the updating 
program. In order to avoid these "window" where the data could change without 
the examiner's knowing it, locking mechanisms were installed in all COBOL 
management report programs. These were the same standard locking mechanisms 
used in data base-updating programs to avoid data modification "collisions." 
The performance benefits of concurrent operations so far outweighed the 
consequences of a "window" data modification that the locking mechanisms were 
removed from all COBOL management report programs. Since at least three of 
the reports were run daily, this design enhancement paid for itself in a short 
period of time. Another concurrency benefit was achieved when the data base 
examine capability was "cloned" from the generalized data base update 
program. This new program allowed the operations staff to perform data base 
inquiries and to track down problems without interrupting the production flow. 
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6.8.2 CSF 

There were few design enhancements required for Landsat-D Prime operations in 
the CSF. In the area of hardware, a new Nascom switch was installed that 
replaced both the matrix switch and the original Nascom switch. It 
considerably simplified the switching of lines and removed several potential 
sources of operator and hardware error. Based on results of performance 
analysis studies for dual spacecraft operations, an additional megabyte of 
memory was added to each of the three CSF VAXes. A dedicated disk drive was 
added to each VAX. These drives were pulled from a MIPS string; the string 
was then dedicated to supporting FSS activities for the two spacecraft. 

In the area of software, there were no enhancements made to PES or TSIM. The 
FOS software was already compatible with Landsat-D Prime but was modified for 
performance enhancement. Significant gains were achieved in memory usage and 
speed. The NCC and FSS software required substantial data base parameter 

updates; some enhancements for performance were also made. The NOAA 

contractor chose to modify file and data names to reflect spacecraft IDs and 
prevent corruption of one set of spacecraft data by the other. The entire 
system architecture (directories, accounts, etc.) was modified to separate the 
inputs and outputs of each spacecraft and embed protective measures to prevent 
corruption of data. 

6.8.3 DRRTS 

For Landsat-D Prime, the TM demultiplexers in DRRTS were required to be 
upgraded to detect the Landsat 5 spacecraft identification in the data 
stream. Software then had to be upgraded to print messages an write into 
files the correct spacecraft identification. Additionally, the TM simulator 
was upgraded to output Landsat 4 or Landsat 5 spacecraft identification. 

The directory generation and MMF service routine software modules were 
significantly optimized to enhance the overall DRRTS throughput. 
Additionally, TM MSCD formatted dump program was developed to aid in 
diagnosing TM MSCD related programs. 
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6.8.4 MIPS 

No hardware changes were required for MIPS to accept Landsat 5 data. The 
system architecture was structured to accept Landsat 5 files from the MMF-M 
for process requests and parameter files, but system messages and reports had 
to be upgraded to print or write in files the appropriate spacecraft 
identification. 

One of the MIPS strings was restructured to support the Control and Simulation 
Facility (CSF) changes for Landsat~D Prime. Three disk drives were removed 
from MIPS string #1 and reinstalled in CSF. 

Additional unconfigured utility and diagnostic software was developed to 
support the MIPS maintenance and operations. Two significant software items 
were: 1) MIPS manager software, and 2) super diagnostic software. The MIPS 
manager software is a tool for functions such as creating and populating MIPS 
directories, editing and dumping parameter files, work order sets and internal 
files, etc. The super diagnostic software provides an easy way to have canned 
sets of diagnostics run using device drivers and exercisers. 

The radiometric correction algorithm was enhanced to implement a limitation 
scheme for the scene content correction algorithm to restrict the divergence 
of corrections on flat radiance scenes (e.g., clouds or water, etc.). 

6.8.5 TIPS 

The TIPS underwent many design enhancements during the period from program 
rebaseline until system turnover. Enhancements were made in the areas of 
software, hardware, system optimizations, algorithms and tools. 

6. 8. 5.1 Software 

Several software enhancements were made in order to increase the operability 
of the TIPS. First, units of work transferred from the MMF-T were placed into 
a hold queue rather than automatically scheduled for processing. This change 
increased the operator's control over the system. Second, in order to reduce 
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the frequency with which the operator was required to purge the disks, disk 
space optimization enhancements were implemented. These included deletion of 
the ASCII MMF-T process request files upon successful incorporation and the 
sharing of non-image data files between various non-concurrent processes. 

6. 8. 5. 2 Hardware 

Six major hardware design enhancements were made in the TIPS system. First, 
an additional pair of RP06 disks were added to each TIPS string for use in 
control point library build. This addition reduced the contention for the 
main image disk pairs. Second, an additional megabyte of memory was added to 
each TIPS string. This change reduced program paging during concurrent 
processing, such as geometric correction and control point library build. 
Third, the downlink synchronization module was modified to detect the 
spacecraft identification in the time source digits of the thematic mapper 
data stream. The fourth major hardware design enhancement was the 
modification of the TM simulator to output Landsat 4 or Landsat 5 spacecraft 
identification. 

The integrity and reliability of the FFP interfaces were greatly enhanced by: 
1) replacing unnecessary cabling by hard wiring, 2) redoing the chassis 
ground, and 3) repositioning the VAX interface to reduce cable length (from 10 
feet to 0.5 feet). 

Finally, the maintainability and operability of the laser beam recorder was 
enhanced by: 1) addition of a photo diode and digital readout to monitor 
laser intensity, 2) addition of an external switch to allow continuous 
generation of gray scale control stock, and 3) interface electrical changes to 
ease several potential race conditions. 

6. 8. 5. 3 Systems Optimizations 

System optimization design enhancements were made in three areas: 70 mm film 
generation, radiometric correction and CCT generation. 
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b.b.5.3.1 /U mm Film Generation 


The GSFC D100C specification states: "At least the following shall be 
recorded on 70 mm film: two TM bands selectable from any of the seven 
available." The real use for 70 mm film is as a quality assessment tool and, 
as such, only one band is required. The TIPS was built with the capability of 
generating either one or two bands of 70 mm film. Operationally, the single 
band option is used in order to minimize film used, disk space used and film 
generation time. 

6. 8. 5. 3. 2 Radiometric Correction 

The RC segment size was first increased from 360 to 720 scans and the number 
of subsegments reduced from three to one. The latter resulted in no 
subsegment smoothing. Later, as a result of a TM radiometric correction R&D 
study, the number of subsegments was increased to six. 

The scene content correction (SCC) is set up as an iterative process. 
Originally, four Iterations were being performed. These were found to be 
excessive as convergence is usually achieved after one pass. A TM radiometric 
correction R&D task checked this out in detail. It was determined that the 
relative radiometric correction performance requirements were being met after 
at most two passes of SCC. Further passes did not improve results. The 
number of SCC passes were then reduced to two for both Landsat 4 and 5. There 
was also a substantial time savings by this reduction. 

6. 8. 5. 3. 3 CCT Generation 

The GSFC D100-C specification requires that the spacecraft maintain "A precise 
swath pattern which will repeat each 16-day cycle within + 5 km maximum." The 
CCT format divided the scene into four quadrants centered at the WRS scene 
center. The image record length was chosen to allow up to a + 10 km variation 
about the WRS scene center, thus generously satisfying the D100-C 
requirement. However, during early post-launch Landsat 5 activation, when the 
spacecraft was a much as 86 km off the WRS, it was impossible to generate CCTs 
of the imagery. The CCT generation software was modified to frame the imagery 
as though the offset were zero, if the cross-track variation was excessively 
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6. 8. 5. 4 Algorithms 

Most of the algorithmic enhancements in the TIPS were in the radiometric 
correction area. The first was to the regression algorithm that computes the 
gains and biases. The previous design used a weighted linear regression 
scheme. The weights were proportional to the number of scans that formed a 
cal state and inversely proportional to the detector noise. This was found to 
be incorrect. Several schemes were tried, but in the end an unweighted linear 
regression design was selected. This was best able to reproduce the 
pre-launch gains and biases, when appropriate pre-launch data was processed. 

There are eight cal lamp states, all of which can be used in the regression 
step to compute the gains and biases. It was noticed that for the brightest 
lamp state (state 111, when all three lamps are on), cal values for some bands 
will saturate. The saturation effect would cause an undesirable effect in the 
regression. It was decided to eliminate states 111 and 000 (when all lamps 
are off) from the regression. 

After the gains and biases are computed using linear regression, they have to 
be checked for validity. Originally, a scheme based on statistical tests was 
used. This, however, only checked the error in the linear fit, but not that 
the fit was reasonable. It was also a CPU intensive process. The new 
algorithm checks that the fit is good as well as reasonable. It does this at 
a substantial savings of time, as only a few additional calculations have to 
be made over the computation of the gain and. bias. 

The histogram adjustment process on certain kinds of data tends to diverge 
instead of converging. A limitation scheme was developed that would restrict 
the process from diverging. It essentially Imposed limits on quantum levels 
over which the histogram means and standard deviations are computed. This 
reduces the possibility of striping. 

0993A 


152 


interval into segments. This invariably leaves a partial segment at the end 
of the interval. Previously, the partial segment was ignored for the 
computation of the RLUTs. The software changed to combine the partial segment 
with the previous full segment, thus allowing for more reliable gain and bias 
computation for this segment. 

Shading factors are used to compute the effective radiance for each detector, 
for each lamp state. The original algorithm was developed under the 
assumption that shading factors wee independent of the lamp state. Thus only 
100 (one for each detector) were necessary. Subsequent analysis indicated 
that this was not so and that 800 shading factors were required. The software 
and parameter files were therefore modified to incorporate this change. 

The only significant non— radiometric correction enhancement control point 
neighborhood (CPN) was in the correlation area. The base dimensions of the 
CPN (128 x 256 pixels) are derived from spacecraft parameter and sensor 
alignment uncertainties. Since these uncertainties are reduced for a given CP 
by knowledge of the CP dislocations for the same general regions, it is 
possible to reduce the search dimensions whenever a statistically good local 
mean is available. The aim is to reduce both dimensions by a factor of two. 
This reduces the correlation time from about four seconds to about one 
second. Further reduction is not considered to be "cost-effective." 

6. 8. 5. 5 Tools 

Three main categories of tools were provided. First, tools were developed 
that enhanced the capability to assess the quality of the TIPS products. 
Second, tools were developed to aid in the evaluation of the TM instrument, 
and the radiometric correction of the Ground Segment. Finally, tools were 
developed for engineering use in debugging problems and assessing 
performance. The development and implementation of comprehensive hardware 
diagnostics greatly facilitated troubleshooting. 


153 


0993A 


6- 8- 5. 5.1 Oualltv Assessment 


CCT Profile was developed to provide a quick quality assessment (but not 
including video) of CCTs generated by the TIPS. CCT Profile: 

a. Gives a profile of the files and records on the CCT-AT or PT physical 

* 

volume . 

b. Provides a detailed formatted dump of the non-image records and the 
prefix and suffix data of a small sample of the image records. 

c. Gives an indication of whether or not the number of records and files 
are in the order as advertised by the file pointer records on the 
tape. 

d. Reports for each band the total number of all replicated lines, the 
maximum number of contiguously replicated lines and the last line 
number of such a swath. 

e. Displays a count of the records in which "read" retries occurred and 
the maximum number of retries for any record. 

6. 8. 5. 5. 2 Radiometric Correction 

For monitoring the thematic mapper instrument, TIPS provides the capability to 
extract calibration lamp, shutter and thermal band calibration source minor 
frames from raw data. The TIPS provides the capability for the recording of 
these minor frames on CCT, together with spacecraft time for the corresponding 
major frame. To facilitate evaluation, the calibration data thus captured can 
be displayed by the PLOTCAL software. In addition, the histograms of the raw 
input data can be examined using the PLOTHIST software. 

Should the calibration data indicate a significant change in sensor response, 
the radiometric correction parameters can be updated using the parameter 
update software. This was a TM radiometric correction R&D task that created 
support software for updating radiometric correction parameters. This package 
is not a part of the production software, but is a very valuable tool for 
maintaining the radiometric correction fidelity. The reason such software is 
necessary is that with time the sensor characteristics change. Radiometric 
correction is very dependent on sensor related parameters such as nominal cal 
values, thresholds, windows, etc. These then need to be modified. The sheer 
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volume of numbers rules out a manual effort. This package provides a way to 
compute and update radiometric correction parameters. 

6 . 8 .5 . 5 . 3 Engineering 

Numerous tools were developed to enhance the engineering capabilities of the 
TIPS. They were: 

a. EHOS - Create and edit engineering work orders. 

b. ETOP - Create and edit engineering TIPS operational parameter files. 

c. EDITTSP — Edit TIPS short-term parameter files. 

d. EDITTLP - Edit TIPS long-term parameter files. 

e. DUMPSCD - Dump systematic correction data files. 


155 


099 3A 



6.9 uRuuND 5t.ufic.Ni t't.Kj’OnHANcr. 

The performance of the Ground Segment is discussed separately for MSS and TM 
imagery. Specific paragraphs describe the performance in relation to: (1) 

radiometric corrections, (2) geometric corrections, (3) system throughput, and 
(4) processing turnaround times. In addition, there is a discussion of the 
Automatic Cloud Cover Assessment (ACCA) in relation to TM imagery. 

6.9.1 MSS DATA PROCESSING 

The following four paragraphs discuss radiometric corrections, geometric 
correction, system throughput and processing turnaround times for processing 
of MSS data. 

6. 9.1.1 Radiometric Performance 

This subparagraph includes two topics: post-launch calibration of the 

sensors, and Ground Segment correction performance. The former summarizes the 
major steps taken to remove sensor striping. The second presents quantitative 
results on performance, which can be compared to requirements. 

6. 9. 1.1.1 Post-Launch Calibration 

Post-launch calibration of the instruments is necessary as the in-orbit 
behavior of the sensors is considerably different from the ambient ground 
environment (where all the pre-launch parameters are determined arbitrarily). 
Also, the sensor characteristics change with time, necessitating further 
updates. 

Post-launch calibration for MSS data processing consists of updating some or 
all of the following parameters: 

a. Nominal Cal values and Acceptance Window. These parameters are used 
to validate the incoming cal data which is used to compute the 
detector response functions (gain and bias values). 

b. Multiplicative and Additive (M&A) constants. These are used to fine 
tune the response functions to reduce sensor striping. 

c. Rmin and Rmax. The radiance range over which the detector values are 
calibrated. 
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1982. The first was required because of the 6Z slide In response of the 
photomultiplier sensors In bands 1, 2 and 3 when exposed to the space 

environment. The second was required to adjust for sensor drifts. 


The Rmax values for bands 1 and 3, which define the upper radiance range for 
those bands, were modified on August 17, 1982. The pre-launch values that had 
been selected turned out to be greater than the radiance values at which some 
detectors saturated. This caused striping in high radiance scenes. The 
change was implemented as a modification to the M (multiplicative) values. 
Thus the pre-launch regression components did not have to be regenerated. 


The Cal Wedge Nominal values were also updated twice. The first time was two 
weeks after launch on July 30, 1982, to again account for the change from 
ground to flight conditions. The second update was made on August 26, 1982, 
to only Detector 9 nominal values. This channel was exhibiting large swings 
in its gain. In addition to the nominal values, the Cal Wedge Acceptance 
Window was also changed from 5 to 6 quantum levels. 


The above updates refer to the PCL (prime lamp, compressed mode, low gain) 
mode of operation of the MSS sensor. This is the primary mode of operation of 
the sensor, as more than 99% of the data is gathered with this mode. 
Post-launch calibration of modes PCH (prime, compressed, high) and PLL (prime, 
linear, low) was also done in December 1982, just before turnover of the 
system to NOAA. 


For Landsat 5, the PCL and PCH mode post-launch calibration parameters were 
determined. These were delivered in June 1984 to NOAA/CSC for installation. 
These consisted of M&A updates, and new Cal Wedge Nominal values. 

6.9.1. 1.2 Performance Evaluation 

The radiometric correction performance is evaluated at the band level on the 
archival product. The requirement is that the system correct the six channel 
values in each band to within + 1 quantum level in a scan, 99. 9% of the time. 
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The quantity used to cVi'lf this requirement Is the range check value, which is 
the range of detector radiances for a scan after removal of scene content 
effects. Scene content adjustment is made by subtracting a seven-line window 
average from the line mean for each detector. Any variation within band 
detectors due to changing scene radiance is then minimized, and a more 
accurate measure of true band striping can be derived. The range check value 
is printed in the PEPG radiance evaluation report only if a range check 
exception occurred; i.e., only if the range check value exceeded the range 
check limit of 2. A count of these range check exceptions for a large number 
of scans is an indicator of the radiometric performance. Another report value 
used to measure the radiometric correction is the radiometric quality 
indicator (RQI) which is the average of the scan range check values over the 
entire scene. Requirements are met if this value is less than 1.33 quantum 
levels. 

Typical examples of RQI are shown in Table 6.9-1. There were no range check 
exceptions over the 2400 scans evaluated. That is, all scans were corrected 
to within specifications. In all cases, the average RQI values are 
considerably less than 1.0, which shows that adequate correction is well 
within the required capability. 


Table 6.9-1. Average RQI Values. Units are Quantum Levels 


Scene 

Band 1 

Band 2 

Band 3 

Band 4 

1 

0.35 

0.43 

0.64 

0.33 

2 

0.34 

0.34 

0.61 

0.31 

3 

0.47 

0.31 

0.49 

0.22 

4 

0.52 

0.35 

0.21 

0.28 

5 

0.28 

0.32 

0.94 

0.14 

6 

0.68 

0.31 

0.79 

0.19 


6. 9. 1.2 MSS Geometric Performance 

The specification for temporal registration performance for the Landsat MSS 
system has been interpreted to mean that features of the registrant image and 
the reference image shall be co-located in cross-track and along-track axes to 
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within 0.3 IFOV 90 percent ot the time. The requirement for geodetic 
rectification is that features of an image registered to a map be co-located 
in both axes with features of a "perfect" map (i.e., no map error) within 0.5 
pixel, 90 percent of the time. The IFOV for MSS is approximately 83 meters. 

Several tasks and analyses made significant contributions towards the 
achievement of the final registration accuracy of the MSS Image Processing 
System (MIPS). The implementation of the line length correction, with line 
lengths determined to subpixel accuracy (a significant departure from the 
Landsat 2, 3 era), reduced the image internal distortions near sweep end 
points from a worst case of + 0.48 pixels to +0.0b pixels. Post-launch 
calibration of data editing and validation parameters, MSS filter control 
parameters and the instrument alignment parameters made significant 
contributions to the system geometric accuracy. The most significant 
contribution to improved geometric performance was the calibration of the MSS 
scan mirror profile. This calibration was achieved using routine outputs of 
the system for scenes with an abundance of well-registered geodetic control 
points (GCPs). 

Table 6.9-2 summarizes the MSS geometric performance accuracy for Landsat 4, 5 
scenes with ten or more well-distributed GCPs. 

The temporal registration accuracy was, in general, estimated from system 
output using error estimation techniques. For a few instances, it was 
measured directly by comparing two geodetically corrected scenes. 32 by 32 
control point chips were extracted from one scene and 64 by 64 control point 
neighborhoods (CPNs) were extracted from the other scene. The offsets of the 
control point chips registration locations from the expected locations in the 
CPNs along with the accuracy of CP registrations, provide the data for 
computing a direct measure of the temporal registration accuracy. A 
comparison of the two approaches showed that while the results from the error 
estimation method were consistent with the direct measurements, the former 
approach gave higher estimates of registration errors. The data in Table 
6.9-2 reflect the more conservative estimates of the system accuracy. 


159 


0993A 


HSS Regia Iraliuu Atuuiat>" 


la Die 6.9-2. 



Pre-Cal Accuracy 
(90%) 

Post-Cal Accuracy 
(90%) 

System Accuracy 
Requirement 

H 

Direction 

Temporal 

Regis- 

tration 

Geodetic 

Regis- 

tration 

Temporal 

Regis- 

tration 

Geodetic 

Regis- 

tration 

Temporal 

Regis- 

tration 

Geodetic 

Regis- 

tration 

4 

Cross- 

Track 

0.41 

0.79 

0.29 

0.37 

0.3 

0.5 


Along- 

Track 

0.25 

0.40 

0.25 

0.34 

0.3 

0.5 

5 

Cross- 

Track 

0.45 

0.50 

Data Unavailable 

0.3 

0.5 


Along- 

Track 

0.27 

0.35 

Data Unavailable 

0.3 

0.5 


* All data values are in units of MSS IFOV * 83 meters. 
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where E^ is the estimate of the pointing error corresponding to the probable 
bias in system state determination caused by the noise in the GCP location 
information and is given by: 

Ej = d 2 *n/2N 
d 


Here, d is the GCP location designation error, n=6 is the number of system 
state vector elements and N (assumed to be 10 for the purpose of Table 6.9-2) 
is the number of GCPs successfully registered. The history of the 90% 
designation errors for Landsat 4 is summarized in Table 6.9-3. For Landsat 5, 
the final post-cal Landsat 4 values are substituted in estimating geodetic 
registration accuracy. 


Table 6.9-3. MSS Control Point Designation Error (Landsat 4) 




Filtered 

Filtered 


Unfiltered 

Designation 

Designation 


Designation 

90% Error 

90% Error 

Direction 

90% Error 

(Pre-Cal) 

(Post-Cal) 

Cross-Track 

0.82 

1.23 

0.41 

Along-Track 

0.82 

0.58 

0.41 


The geodetic registration accuracy was evaluated using a direct approach (see 
paragraph 6. 9. 2. 2) and was shown to be consistent with the preceding method. 

For Landsat 4, from Table 6.9-2, it is apparent that both temporal and 
geodetic registration accuracy requirements are fully met. For Landsat 5, 
post-cal performance data is not available at present. However, comparison 
with Landsat 4 data suggests that when the data base is updated to reflect 
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6. 9. 1.3 MSS Throughput 

During the Buy-off Demonstration In October 1982, the system was shown to have 
the capability to throughput 200 scenes per day within 85 percent of a 
two-shift day. To meet the 200 scenes per day requirement, each MIPS string 
must be capable of 67 scenes In 13.6 hours. The demonstration was accepted. 

6. 9. 1.4 MSS Processing Turnaround Times 

Turnaround times for MSS data processing were determined during the October 
1982 Buy-off Demonstration. Information to establish actual Ground Segment 
performance for turnaround time was derived by tracking tapes as they 
progressed though the system. The most significant observation that can be 
made is that about 75 percent of the tapes were processed in less than 48 
hours, whereas others took over 48 hours. Detailed studies of the progress of 
the tapes through the system indicated that for those tapes exceeding 48 hours 
the causes of the delays were procedural in nature and can be corrected. 
Operational procedure changes were proposed to make it possible to meet the 
48-hour turnaround requirement. 


6.9.2 TM DATA PROCESSING 

The following five paragraphs discuss radiometric correction, geometric 
correction, system throughput, processing turnaround times, and automatic 
cloud cover assessment for TM data processing. 

6. 9. 2.1 TM Radiometric Performance 

Like its MSS counterpart, this paragraph also reviews the major post-launch 
calibration efforts and quantifies the radiometric performance. 

6. 9. 2. 1.1 Post-Launch Calibration 

The TM radiometric correction is much more dependent on parameters than are 
the MSS algorithms. This is partly because of the increased number of 
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complex online correction that takes place. Examples of parameters are data 
extraction MNFs (minor frames), nominal values, acceptance windows, 
thresholds, regression weights, lamp radiances and thermal band coefficients. 
Like MSS, an initial set of values was determined for both Landsat 4 and 5 
from pre-launch data. Some of the parameters were updated soon after the 
respective satellite launches, to account for flight conditions. These 
consisted mainly of changes to nominal cal values and data extraction MNFs. 
Updates to the other parameters were made during the subsequent TM R&D period 
to enhance performance. The remainder of this section discusses five updates 
of major significance. The changes apply to both Landsat 4 and 5 data 

processing, unless otherwise indicated. 


6. 9. 2. 1.1.1 LBR Tables 

The generation of 241 mm film products makes use of LBR gamma tables. In July 
1983, new band-dependent tables were installed. These were designed to bring 
out the best contrast in the imagery. This was a joint effort by NASA, EDC 
and GE. 


6. 9. 2. 1.1. 2 Thermal Band Radiance Range 

The thermal band data was originally calibrated to a temperature range of 260 
to 320°K. This resulted in many dark scenes over high latitudes in winter. 
The calibration range was therefore expanded to 200 to 340°K in September 
1983. This change also made the TIPS thermal band processing compatible with 
Scrounge . 


6. 9. 2. 1.1. 3 Reflective Bands Radiance Range 

In January 1984, new radiance ranges were installed for the reflective bands. 
This set of Rmin and Rmax values was provided by the NASA Science Office. It 
was implemented after exhaustive testing to check its Impact on ACCA, LBR 
tables and CP processing. 
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6. 9. 2. 1.1. 4 Light Leak 

Landsat 5 TM contains a light leak in the shutter flag, between the edge of 
the lenses and the flag body. This results In a secondary pulse In the 
calibration region. Analysis showed that this secondary pulse would not 
affect the correction, except for state 8 for all reflective bands, and state 
7 for band 5. By changing the extraction thresholds and the weights for these 
states in the parameter file, the effect of the light leak was minimized. 
This change was made in March 1984. 

6. 9. 2. 1.1. 5 Absolute Radiometric Correction 

The absolute radiometric correction of TM data was evaluated using pre-launch 
Landsat 5 integrating sphere data, and in-orbit Landsat 4 and 5 overlap data 
of March 15, 1984. As a result of the analysis, two changes were made. 
First, the regression algorithm was changed from a weighted to an unweighted 
scheme. This consisted of both software and parameter changes. Second, lamp 
radiances for band 3 (Landsat 5 only) were computed from in-orbit data, to 
correct for the difference between the gains for odd and even channels. These 
changes went into effect July 1984. 

6. 9. 2. 1.2 Performance Evaluation 

The algorithm used to measure the TM relative radiometric correction 
performance is similar to that used for MSS. The range of the 16 channel 
values is computed on a scan basis on the HDT-AT data. This is done by the 
range check option in the 1M data quality (TDQ) package. The requirement is 
that the system correct to + 1 quantum level out of 256. This means the scene 
content removed range for each scan shall never exceed 2 quantum levels. 

Tables 6.9-4 and 6.9-5 are typical examples for Landsat 4 and 5 performance. 
The Landsat 4 correction is as of November 1983, while the Landsat 5 numbers 
date from July 1984. The tables show average RQI numbers over areas selected 
from different scenes. Numbers in parentheses indicate the number of scans 
that exceeded the two quantum level limit. The areas indicated were selected 
from several different scenes. 
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Table 6.9-4. Landsat in Kadiomecric Correction 

(The Offline Radiometric Quality Indicators (RQI) units are quantum 
levels. Numbers in parentheses indicate the number of scans that exceeded 
the 2 quantum level limit.) 



# OF 
SCANS 


32 

26 

32 

32 

32 

32 

32 

32 

32 




5 

6 

.90 

.23 

.61 

.26 

.85 

CM 

CM 

• 

1.01 

.24 

.87 

.30 

.85 

.26 

.69 

.24 

.70 

.23 

.74 

.31 



3.95 (7) 
1.91 (6) 
3.60 (32) 
.89 

1.33 (10) 
.97 

1.54 (2) 
.87 
.92 



# OF 
SCANS 


32 

32 

32 

32 

32 

13 



1 

2 

3 

4 

5 

0.38 

0.69 

0.40 

0.37 

■B 

0.48 

0.66 

0.53 

0.40 

n 

0.87 

0.76 

1.71 

0.36 

0.56 

0.58 

0.71 

0.52 

0.57 

0.58 

0.60 

0.62 

0.52 

0.62 

0.53 

0.72 

0.66 

0.60 

0.56 

0.52 
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For Landsat 4, only some band 7 data are Is not being corrected to 
specification. This is only for scenes with many low radiances values, such 
as water. The reason is that channel 7 in band 7 is twice as noisy as the 
other channels. This causes much low radiance data to fall below the DC 
restore level, which results in the scene content correction process 
diverging. Limitation schemes to the SCC process have been implemented 
lately, which reduce this divergence. Updated numbers for Landsat 4 are not 
available. Landsat 5 correction is well within requirements and all channels 
are behaving properly. 

6. 9. 2. 2 HI Geometric Performance 

The specification for temporal registration performance for the Landsat TM 
system has been interpreted to mean that features of the registrant image and 
reference image shall be co-located in cross-track and along-track axes to 
within 0.3 IFOV 90 percent of the time. The requirement for geodetic 
rectification Is that features of an image registered to a map be co-located 
in both axes with features of a "perfect" map (i.e., no map error) within 0.5 
pixel 90 percent of the time. The IFOV for TM is approximately 30 meters. 

The compliance of the 1M geometric performance with system specifications was 
made possible by several significant enhancements to the ground processing 
system beyond the optimization of the parameters related to the geometric 
correction process. The enhancements to the radiometric correction process 
were crucial to the improved correlation surfaces that lead to improved 
subpixel registration accuracy for the control points (CPs). Calibration of 
the alignment of the primary focal plane bands with the bands of the cold 
focal plane removed a significant source of error in the control point 
locations as the control point library contains chips extracted from bands of 
both focal planes. This calibration amounted to alignment corrections of 0.7 
pixels along-track and 0.2 pixels cross-track. 

Table 6.9-6 summarizes the results of the direct measurements of temporal and 
geodetic registration accuracy for Landsat 4. Tables 6.9-7 and 6.9-8 
summarize the registration accuracy assessment for Landsat 5 by the methods of 
error estimation and direct measurements, respectively. 
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Table b.9-6. Temporal Registration and Geodetic Reccif icacion Performance 

of Landsat-4 by Direct Measurement 


TEMPORAL REGISTRATION 








NUMBER 

REGISTRATION ERROR 




OF 

CROSS-TRACK 

ALONG-TRACK 

PATH/ROW 

DAY 1 

DAY 2 

POINTS 

(PIXELS, 90%) 

(PIXELS, 90%) 

17 35 

123 

155* 

24 

0.30 

0.32 

17 36 

123 

155* 

20 

0.35 

0.31 

17 36 

123 

187 

34 

0.16 

0.25 



WEIGHTED MEAN 

0.25 + 13% 

0.29 + 13% 

; GEODETIC RECTIFICATION 








NUMBER 

REGISTRATION ERROR 




OF 

CROSS-TRACK 

ALONG-TRACK 

PATH /ROW 

DAY 1 

DAY 2 

POINTS 

(PIXELS, 90%) 

(PIXELS, 90%) 

17 35-39 

155 

155* 

107 

0.52 

0.56 

23 36-37 

101 

101* 

23 

0.46 

0.32 

27 32-33 

97 

49* 

37 

0.47 

0.55 



WEIGHTED MEAN 

0.50 + 8% 

0.52 + 8% 








♦Reference scene 
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Table 6.9-7. 


Temporal Regia LiaLlOii dim 


WCUUCL.b 


Performance of Landsat 5 by the Method of Error 


Estimation 


REGISTRATION ERROR 



NUMBER 

CR0SS- 

TRACK 

AL0NG-TRACK 


OF 

( PIXELS 

, 90%) 

(PIXELS, 

90%) 

SCENE ID 

CPs 

TEMPORAL 

GEODETIC* 

TEMPORAL 

GEODETIC* 

5T0240320130 

11 

0.33 

0.52 

0.34 

0.53 

5T0240330130 

11 

0.28 

0.49 

0.22 

0.46 

5T0240340130 

24 

0.30 

0.50 

0.30 

0.50 

5T0240350130 

20 

0.27 

0.48 

0.30 

0.50 

5T0240360130 

17 

0.25 

0.47 

0.39 

0.56 

INTERVAL 

83 

0.29 +11% 

0.49 

0.32 +11% 

0.51 

A nominal E^ 

“ 0.4 pixel in each 

direction has 

been used, 

and this 


exceeds the measured E. for LS-4 CPs. 
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Table 6.9-8. Temporal Registration and Geodetic Registration 
Performance of Landsat 5 by Direct Measurement 

TEMPORAL REGISTRATION 

REGISTRATION ERROR 






CROSS- 

ALONG- 




NUMBER 

TRACK 

TRACK 




OF 

90% ERROR 

90% ERROR 

PATH/ROW 

DAY 1 

DAY 2 

POINTS 

(PIXELS) 

(PIXELS) 

24/34 

130 

146 

13 

0.19 + 28% 

0.22 + 28% 


GEODETIC 

REGISTRATION 









REGISTRATION ERROR 
CROSS- ALONG- 


DAY 1 

DAY 2 

NUMBER 

TRACK 

TRACK 


(LS5- 

(LS4 REF 

OF 

90% ERROR 

90% ERROR 

PATH /ROW 

SCENE) 

SCENE) 

POINTS 

(PIXELS) 

(PIXELS) 

24/34 

7/9/84 (130) 

9/30/82 

20 

0.43 + 22% 

0.38 + 22% 

24/13 

130 

9/30/82 

13 

0.57 + 28% 

0.63 + 28% 

INTERVAL 

COMPOSITE 

130 

9/30/82 

33 

0.50 + 17% 

0.49 + 17% 
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The system-generated error estimates «ie based 
residuals and the estimated pointing error that corresponds to the bias 
error In the system state vector estimate caused by the noise in CP location 
and is given by: 


HPH 


Here H is the measurement matrix and P is the covariance matrix driven by the 
CP location noise. For temporal registration, the source of the noise is 
correlation noise and the random image error. For geodetic registration, the 
correlation noise is replaced by a much larger noise - the CP designation 
error. 


The direct measurement approach for TM temporal registration error assessment 
was the same as for MSS (see paragraph 6. 9. 1.2). The direct measurement 
approach for geodetic registration error assessment used the CP Library Build 
(CPLB) process. It consisted of designating control points in corrected 
imagery using a Zoom Transferscope to overlay the imagery onto a map. The 
offsets of designated locations from the system predicted locations based on 
known longitude /latitude of the CP were determined. 

The geodetic error E was then computed from the 90% offset error E-.,... v 

gx Ur r — A 

as follows: 

2 2 2 

E = E - D 

gx OFF-x x 

The CP designation 90% error was computed from the CPLB filtered RMS 
residuals: 

D 2 = RMS 2 * 1.645 2 - E 2 
XX tx 

where E is the 90% temporal registration error of the system. 

From the tabulated results, it is clear that both methods of registration 
error assessment are consistent with each other and that both Landsat 4 and 
Landsat 5 TM systems meet the geometric accuracy requirements. 
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6.9. 2. 3 TM Throughput 

Data throughput capability for TM processing was documented with two 
demonstrations. The first demonstration was conducted during October 1983 and 
the second during July and August 1984. 

During October 1983, TIPS demonstrated the capability to process, at a 
sustained level, 12 scenes per day to film and two scenes per day to CCTs over 
a 10-day period. Scene throughput demonstrated was the actual processing of 
averages of 12.8 scenes per day to HDT-P, 12.5 scenes per day to film, and 2.1 
scenes per day to CCTs. 

TIPS specifications called for the production capability to be increased to 
reach daily thematic mapper image totals of: (1) 100 scenes processed through 

TAG (HDT-A tape), (2) 50 scenes processed through TIG (HDT-P tape), (3) 50 
scenes recorded on 241 mm film, and (4) 10 scenes recorded on computer 

compatible tape (CCT-A or CCT-P). In addition, there was a requirement to 
generate control point chips at an average rate of 100 chips per day. The 
ability to meet these higher throughput rates was demonstrated during the 
period July 30, 1984 through August 8, 1984. All specified daily production 
rates were met, or exceeded, during this demonstration of sustained 
performance. 

With each of the TIPS processes (TAG, TIG, Film, or CCT generation) the time 
required per scene varies inversely with the number of scenes per interval. 
Tables 6.9-9 and 6.9-10 illustrate the relationships between interval size and 
time for processing one scene with each of the four TIPS processes. These 
tables were generated from data extracted from the Production Logs for the 
demonstration period. A regression equation relating total processing time to 
interval size was developed for each process. Table 6.9-9 shows the average 
number of minutes required to process an interval containing a given number of 
scenes, while Table 6.9-10 shows the average number of minutes required to 
process each scene according to interval size. 
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Table 6 

.9-9. 



Interval Processing Times 


during August 1984 



TIPS Demonstration 



(minutes per interval) 


SCENES 





PER 



TFG 

TFG 

INTERVAL 

TAG 

TIG 

FILM 

CCT 

1 

14.9 

31.1 

21.7 

35.4 

2 

18.1 

38.7 

30.8 

59.8 

3 

21.3 

46.3 

39.9 

84.2 

4 

24.4 

53.9 

49.0 


5 

27.6 

61.5 

58.1 


6 

30.8 

69.1 

67.2 


7 

34.0 

76.7 

76.3 


8 

37.2 

84.3 

85.4 


9 

40.3 

91.9 

94.5 


10 

43.5 

99.6 

103.6 


11 

46.7 

107.2 

112.8 


12 

49.9 

114.8 

121.9 


13 

53.1 

122.4 

131.0 


14 

56.2 

130.0 

140.1 


15 

59.4 

137.6 

149.2 


16 

62.6 

145.2 

158.3 


17 

65.8 

152.8 

167.4 


18 

69.0 

160.4 

176.5 


19 

72.1 

168.0 

185.6 


20 

75.3 

175.7 

194.7 


21 

78.5 

183.3 

203.9 


22 

81.7 

190.9 

213.0 


23 

84.9 

198.5 

222.1 


24 

88.0 

206.1 

231.2 


25 

91.2 

213.7 

240.3 


TAG: 

T = 

3.18 n 

+ 11.72 


TIG: 

T - 

7.61 n 

+ 23.45 


FILM: 

T = 

9.11 n 

+ 12.54 


CCT: 

T * 

24.38 n 

+ 11.05 


T - 

minutes 

per interval 


n * 

scenes 

per interval 




Table 6.9-10. 

Scene Processing Times 
during August 1984 
TIPS Demonstration 
(minutes per scene) 


SCENES 

PER 

INTERVAL 

« 

TAG 

TIG 

TFG 

FILM 

TFG 

CCT 

1 

14.9 

31.1 

21.7 

35.4 

2 

9.0 

19.3 

15.4 

29.9 

3 

7.1 

15.4 

13.3 

28.1 

4 

6.1 

13.5 

12.2 


5 

5.5 

12.3 

11.6 


6 

5.1 

11.5 

11.2 


7 

4.9 

11.0 

10.9 


8 

4.6 

10.5 

10.7 


9 

~ ‘4.5 

10.2 

10.5 


10 

4.4 

10.0 

10.4 


11 

4.2 

9.7 

10.2 


12 

4.2 

9.6 

10.2 


13 

4.1 

9.4 

10.1 


14 

4.0 

9.3 

10.0 


15 

4.0 

9.2 

9.9 


16 

3.9 

9.1 

9.9 


17 

3.9 

9.0 

9.8 


18 

3.8 

8.9 

9.8 


19 

3.8 

8.8 

9.8 


20 

3.8 

8.8 

9.7 


21 

3.7 

8.7 

9.7 


22 

3.7 

8.7 

9.7 


23 

3.7 

8.6 

9.7 


24 

3.7 

8.6 

9.6 


25 

3.6 

8.5 

9.6 

11.72 


TAG: 

t - 

3.18 + 

n 

23.45 


TIG: 

t * 

7.61 + 

n 

12.54 


FILM: 

t - 

9.11 + 

n 

11.05 


CCT: 

t ■ 

24.38 + ■ 




n 


t “ minutes per interval 
n ■ scenes per interval 


The TM Ground Segment design provides sufficient reserve capability to survive 
and fully recover from a major data-loss occurrence. (The system recovered 
from a loss of 402 archival scenes, 62 scenes on film, and 20 scenes on CCTs 
because of a TIPS-1 TAG problem during the demonstration.) Actual performance 
exceeded 120 percent specified performance. 

6.9. 2.4 TM Processing Turnaround Times 

Data turnaround capability for TM processing was documented with two 
demonstrations. The first demonstration was conducted during October 1982 and 
the second during July and August 1984. 

During the October 1983 demonstration of the TIPS, the timeline requirement to 
process data within 48 hours was met for 70 percent of the products. The 
demonstrated turnaround time averaged 43.88 hours. 

During the second TM Ground Segment Demonstration, performed in August 1984, 
it was shown that the TM Ground System can process data on a sustained basis 
within prescribed timelines. A total of 95 percent of all demonstration 
scenes were processed within 48 hours. 

Quality of output data was maintained during the second demonstration at 
established levels of acceptability. Film acceptance rate was 97 percent, 
while CCT acceptance rate was 98 percent. System availability was 95 percent. 

6.9. 2.5 ACCA 

The evaluation of ACCA scores for Landsat 5 images was performed after 
radiometric calibration on Landsat 5 data had been completed. In order to 
evaluate its impact on ACCA thresholds to ensure the accuracy of ACCA scores, 
241 mm films were used to measure the cloud-cover percentage. A scene was 
divided into four quadrants and each quadrant further divided into 100 
squares, with each square representing one percent of area coverage. Based on 
the contents of bands 3, 5 and 6, the cloud cover was measured manually by 
counting the number of cloud cover squares to obtain scores for each 
quadrant. Then, these scores were compared to the corresponding ACCA scores 
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frees TAG quality assurance reports. The current thresholds sre sufficient 
produce a reasonable cloud cover percentage for Landsat 5 data. 
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6.10 OUTPUT PRODUCTS 

The output products of the Landsat Ground Segment are archival tapes, 241 mm 
film and computer compatible tapes. 

6.10.1 ARCHIVAL TAPES (A-TAPES) 

A-tapes are high density tapes, radiometrically corrected, with tables 
included to permit geometric corrections to any of three map projections: 
Space Oblique Mercator, Universal Transverse Mercator or Polar Stereographic. 
These tapes are maintained in NASA or NOAA facilities. 

6.10.2 241 MM FILM ROLLS 

241 mm film rolls contain first-generation, fully-corrected, positive film 
scenes. This film size provides an image/ground scale of 1:1,000,000; i.e., 1 
millimeter on the film represents 1 kilometer on the ground. These are sent 
to EROS Data Center in Sioux Falls, South Dakota, a Department of Interior 
facility, from which any customer may purchase a print. 

6.10.3 COMPUTER COMPATIBLE TAPES 

Computer compatible tapes (CCTs) are either fully corrected tapes (CCT-PT), or 
radiometrically corrected tapes (CCT-AT) with tables included for geometric 
corrections to two map projections. Four TM CCTs (one for each quadrant) are 
provided for each 185 X 170 kilometer scene from either the A-tape or from the 
fully corrected P-tape, in all seven spectral bands. These tapes are sent to 
EROS Data Center, from which copies may be purchased by any customer. 

6.10.4 QUALITY ASSURANCE (QA) 

QA was provided for TM products by visual inspection of each 241 mm film image 
produced and by examination of computer printouts for other products. Those 
products failing to meet established quality levels (specified in SOPs) were 
either regenerated or cancelled. See Figure 6.0-2. 

Improvements were made steadily, so that in the last few months of the 
contract, no rejections were necessary for video (radiometric or geometric) 
causes. Incidents of severe pixel noise were shown to be caused by: 1) 
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ground etatlnn reception at elevation angles less than 8° (i.e.. range to 
spacecraft greater than 2300 kilometers), or within 8° of the Sun line; and 
2) known sources of interference, mainly Defense Department radars. 

All* TM 241 mm film rejected in the past few months of the contract were 
attributable to non-video causes: density, dimension and line-start of the 

laser beam recorder. 

6.10.5 OUTPUT STATISTICS 

Refer to paragraph 4.5.3 in Volume I of the Final Report for an extensive 
discussion of the number of scenes acquired by TM through 1983, the involved 
ground stations and data evaluations of the TM and MSS products. User 
judgments of the TM quality were: radiometric - "quite good"; geometric - 

"remarkably good"; and application potential - "most useful". 

As of August 31, 1984, the TM instrument had collected, via Landsat 4 and 
Landsat 5, a total of 22,871 scenes. The area of the scenes acquired is 719 
million square kilometers, an area nearly five times the area of all land 
masses on Earth. 13,927 of these scenes have been converted to archival tapes 
and stored in NASA/NOAA facilities. 4093 scenes on 241 mm film have been 
shipped to the EROS Data Center, plus 856 (sets of four quadrant tapes) CCTs. 
Table 6.10-1 shows details. 


0996A 


C- 3 > 


176 

















6 . 11 LESSONS LEARNED 

Looking back objectively, hindsight provides judgments and observations that 
may enhance the performance and quality of subsequent programs. The items 
described in this section of the report are presented for that purpose. 

6.11.1 PROGRAM MANAGEMENT AND SYSTEMS ENGINEERING 

a. The development of a close working relationship with NASA managers 

was Instrumental in focusing attention on key problem areas, 

establishing priorities and resolving critical issues to achieve 
program objectives. 

b. In responding to the challenge of building a "production" data 

processor of data from an R&D instrument, the performance of which 

was undefined, an extraordinary amount of attention and planning was 
given to key processes and the way they would interact. TIPS was 
designed to be modular to facilitate the modification of major 
functions or processes with minimal impact to others, as instrument 
and ground processing performance became better understood and 
practical limitations defined. 

c. A comprehensive engineering and interactive capability was included 

to facilitate development as well as data and process analysis. As 
system needs became clearer during TIPS implementation, this 

capability was redefined and improved. 

d. The use of Program Directives to control funding and document 
requirement changes provided an effective means to control the 
program. 

e. The Cost Performance Measurement System (CPMS) provided an effective 
tool to measure cost and schedule performance. 

f. The preparation of a Ground Segment Management Plan provided a means 
to define organizational responsibilities and publicize them. 

g. Completed definition of external and internal interfaces is critical 
to on-schedule project development. This includes generation of 
interface control documents (ICDs), formal ICD approval by all 
interested parties, and rigid control of post-approval ICD change. 
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Completed definition of overall system specifications (a n 
Segment specification) is mandatory before development proceeds 
beyond a severe breakage point. 

The detailed effort spent defining building layout, power 
distribution, air conditioning and ground distribution minimized the 
potential problems after equipment installation. 

The use of an Engineering Review Board to discuss initial 
requirements, test plans, test results, hardware and software changes 
provided an effective tool to discuss the technical merits of an 
issue, schedule activities and encourage customer participation in 
the development process. 

The rebaseline, completed in September 1980, placed increased 
emphasis on cost and schedule control. As a result, several new 
actions were introduced: 

1) Cost Performance Measurement System (CPMS) allowed each cost 
account manager to track his cost performance against schedule. 
Monthly reports were available for trends and were given to NASA. 

2) Weekly review of financial data by contractor, program manager 
and NASA managers highlighted problem areas and forced solutions. 

3) Increased emphasis was placed on organizational responsibilities 
and budgets and other changes controlled by Program Directives. 

In turnover to NOAA, important considerations are: 

1) A well thought-out plan, agreed to in advance, was crucial to 
the successful turnover. 

2) The ability of the incoming contractor to capture incumbent 
personnel and the use of a small engineering core team allowed 
activities after turnover to be successful. 

3) Use of video tapes for training was extremely successful as it 
allowed flexibility for the students to review material daily 
and to provide a library of the original instructor’s knowledge. 

Undersized DRRTS CPU/memory requirements result in: 

1) Inability to meet concurrent requirements for DECNET transfer to 
MMF with the directory generation. 

2) Need to drop creation of image data quality files during the 
directory generation process to make the process work. 
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Neglect of this resulted in many substantial revisions to the MMF 
service routines. 

o. The key to the successful operations of the MSS portion of the Ground 
Segment is adequate resources. These include: 

1) Financial - adequate funding to perform the mission, while still 
being able to use flexibility for other activities 

2) Schedule - adequate time to perform the necessary tasks 

3) Personnel - the key technical and operational contributors and 
leaders remained on the program through operations and turnover 

4) Hardware - there were extra resources to accommodate operations 
activities, maintenance of both hardware and software, and 
additional development of changes. 

p. Early emphasis on the importance of operational concepts during the 
system development was required to ensure ease of operations. 

q. Management push, both from the NASA Project Office and from GE, to 
force turnover of the system to operations was necessary to ensure 
adequate time for training and to start exercising the system in an 
operational manner. The latter uncovered problems not found during 
integration and test. 

r. Combined responsibility for operations and remaining development 

under one manager allowed the proper resources and priorities to be 
assigned. 

s. The use of written directions and action items by the Mission 

Operations Manager ensured that GE was responding to well-considered 
and approved NASA direction. 

t. The use of video tapes for training was extremely useful for 

cross-training and refurbishment of knowledge. 

u. Daily formal reports on operations progress and problems focused 
resources and fixed priorities in a timely fashion. 

6.11.2 HARDWARE DEVELOPMENT 

a. Early use of technical experts in developing design and manufacturing 
guidelines for the complex, high-speed equipment was valuable, 
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system. 

The use of wire-wrap concepts allowed modifications for engineering 
changes (upgrades and errors) at relatively low cost. 

A greater emphasis on using off-the-shelf parts for key assemblies 
(backplanes, devices) could have reduced the technology risks. In 
some areas, e.g., MMF, where off-the-shelf items were used nearly 
100%, a stable development and operations environment existed. 

Rigid adherence to preventive maintenance schedules resulted in a 
reliable hardware system, where outages were infrequent and of short 
duration. 

In a long-development program, upgrading vendor supplied ADP hardware 
is required. This keeps pace with the technology, helps computer 
professional employee morale, results in higher reliability and lower 
life cycle maintenance costs. 

Transportable Ground Station. The TGS was a highly successful 
project, delivered on time and meeting or exceeding all of its 
performance requirements. This success is directly attributable to 
the skill, experience, and cooperation of the NASA, SA, and GE 
personnel involved in its design and implementation. This is a 
lesson which can never be relearned too often. Other lessons learned 
in this development were: 

1) Careful implementation of redundancy in the system and the 

careful selection of the test equipment complement which 
provides built-in end to end testing and short loop testing, 
ensures the capability to maintain system performance and system 
availability at a high level of readiness. 

2) The most severe problem experienced in the TGS project resulted 

from the failure of the antenna foundation studs to be properly 

positioned in the concrete by the facilities subcontractor even 
though a template had been supplied for this purpose. This 

problem was detected in November of 1980 and considerable effort 
was expended in resolving the problem. The foundation is steel 
reinforced concrete, 22 feet in diameter, four feet deep. 
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Twelve anchor bolts one end cr.e-feurth inch in diameter by 2? 
inches in length, with 8 inch square welded steel baseplates 
were to be embedded in the concrete on a 70 inch bolt circle. 
These studs were to extend above the concrete four and one-half 
inches for attachment of the antenna base extension. Efforts to 
reposition the bolts Included bending, cutting, addition of 
couplings, an additional layer of concrete, and testing of the 
repairs. It was discovered at the initial attempt to install 
the base extension that the bolts, still were not located within 
the required tolerances. This required counterboring the base 

extension holes and the design of steel plate washers in order 
to assure suitable stiffness. During the subsequent 

installation of the base extension it was found that one 
of the bolts would not survive the required torque. Finally, 
twenty-four additional studs were installed through the base 
into the concrete using parabond anchors. This was followed by 
a weekly test program lasting a year to verify the integrity of 
the repair. In retrospect, the lesson learned is that the 
initial reaction when the problem was first detected of tearing 
out and rebuilding the foundation would probably have been the 
most satisfactory and cost effective solution to the problem. 

3) The TGS test capability includes test couplers in the sum 

channels after the feeds to permit injection of test signals as 
one means of verifying system performance. The signal is 
upconverted for X-band using the same local oscillator as the 
X-band downconverter. A failure of the local oscillator to lock 
on frequency was masked in this test mode as the oscillator 
drift was common to both the up and down conversion channels. 
The problem was detected by attempting to lock on to the 
boresight tower test signal. The obvious solution to this 

problem would be the use of separate local oscillators for up 
and down conversions. 

A) Parametric amplifiers were used in both the C-band and in the 

S-band channels in order to achieve the required G/T 
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GaAs FET low noise amplifier technology advanced to the state 
that equivalent G/T performance could be met in S-band using 
GaAs FET LNAs , and X-band LNAs which were within .8 dB of the 
para-amp performance. Consequently, GaAs FET LNAs where used as 
spares for the para-amps at considerable savings in cost. These 
amplifiers have been used temporarily to replace failed 
para-amps with little or no noticeable reduction in overall 
system performance, because of system margin. Current X-band 
LNAs are available with performance within .3 dB of the para-amp 
specifications. Repairs to the para-amps should be made only as 
long as the cost of repair is less than the cost of the GaAs FET 
LNAs with similar performance. The FET LNAs are far more 
reliable than the para-amps. 

Early in the TGS design cycle, heaters were recommended for the 
antenna reflector. This recommendation was rejected because of 
the additional cost involved and because the planned use of the 
TGS at that time was not primary US data collection source for 
X-band data. As a result there are three or four days per year 
during which the TGS is unable to receive data because of snow 
and ice accumulation on the reflector. Reception is impaired or 
impossible not only because of the added load to the servo 
drives but more importantly because the ice build up defocuses 
the antenna. Installation of heaters bonded to the reflector at 
this time is not feasible because disassembly and sandblasting 
of the reflector would be required and the procedure would be 
very expensive. Etheylene Glycol anti freeze solution would 
solve the problem but is not recommended for environmental 
reasons. The only other solution is flowing heated air onto the 
reflector exercising care such that the reflector contour is not 
thermally distorted. This approach has not been implemented as 
a trade off between cost and the amount of lost data does not 
appear to warrant it at this time. 
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associated RF components are pressurized to prevent moisture 
build up; a dry air compressor automatically maintains system 
pressure. Low pressure is indicated by an alarm light. For 
unknown reasons, the radome developed a crack allowing rain 
water to accumulate in the feed. Unfortunately, the accumulated 
water in the feed exceeded the air pressure head such that the 
low pressure alarm was not activated. The lesson learned is 
that the low pressure sensor should have been located in the 
feed rather than down stream from the feed. 

During the operational readiness check-out of the TGS prior to 
the Landsat 5 launch it was found that there were a considerable 
number of problems and that system performance was substandard. 

A number of the problems were in the X-band system which had not 
been used since the failure of the X-band frequency source on 
Landsat 4. Other problems were masked by the system design 
margins which permitted usable data to be acquired even though 
performance was degraded. This situation resulted from 

operation of the system by contractor personnel not fully 
trained in system maintenance and test. The lesson is that 
sophisticated equipment, even though designed to be fault 
tolerant and provided with redundancy to maximize availability, 
requires trained skilled maintainers. The system was restored 
to full operational capability utilizing the built-in test 
equipment capability, and required maintenance was performed and 
demonstrated to the contractor personnel. 

System performance of the TGS with regard to data analyzed from 
Landsat 4 and compared to that received from Landsat 4 was 
virtually identical, demonstrating the integrity of the 
spacecraft to ground station performance. 
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Software is a new field compared to hardware and, as such, does not have the 
extensive history of hardware design and development methods. On Landsat A, 
proper emphasis was not given to software developement and methods early in 
the program. 


a. Coding was initiated prior to completion and review of system 

requirements definitions. This led to false starts and continuing 
revision as the system requirements became firmer. The lesson 

learned here: premature coding is expensive; wait until reasonably 

firm system requirements are available. 

b. Development of metric for performance is essential if progress is to 

be controlled. There must be known measurement points in the 
software development program and planned versus actual charts must be 
kept. Realistic performance goals are essential to track the 
effort. Updating mission requirements often requires replanning, 

that in turn may mask impending problems. A thorough management plan 
is essential; coding and testing standards must be set up and 
followed. 

c. Software turnover control: there should be phased software turnover 

at specific points in the program, from the smallest functional and 
lowest level of documentation through the entire system performance 
and test program. Systems Engineering is important throughout the 
turnover control to provide the facility viewpoint and to input and 
upgrade the interfaces and requirements as the effort progresses. 
Uniform development among the facilities is desirable so that 
suitable coordination can be obtained; i.e., if a facility is 
completed early, don't overwhelm it if other portions of the system 
are in trouble. 

d. The structural programming concepts based on the GE SEAM Manual used 
for Landsat software development were successful in ensuring that the 
development process met the schedule and the resulting code was 
maintainable. Changes/modifications to programs were easily isolated 
and identification of all affected modules easily performed. 
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c. Carryover of software fro™ earl nrnjprtfi was. in general, not 
successful, due to different development personnel and different 
computers used. 

f. The unified organization of system programmers forced commonality 
into hardware driver development and system architectures. 

g. The rigid coding standards employed in the software development phase 
made maintenance easier. Due to these standards, tools to analyze 
source code (for configuration management, lines of code counts, data 
dictionary development, etc.) were automated, which resulted in 
precise and accurate information system support services. 

h. The use of pre-programmed sets of standard in-line comments (e.g., 

prologues) and executable code (e.g., standard error handling) led to 
software module "skeletons" that greatly reduced the amount of coding 
needed to develop a piece of software. 

i. DRRTS software subcontractor work was not closely monitored and 

resulted in: 

1) Software breakage 

2) Necessity to redesign completely the directory generation 
software 

j. The complexity of the functions and interfaces of the MSS control and 

communication software, as well as the monitor software for 

individual packages, were underestimated. This resulted in a 
significant increase in the effort in software development and 
testing. 

k. The software development cycle was started before the system level 

requirements were fully established, resulting in substantial 
software breakage. For example, the entire MAG package developed up 
to Build No. 1 was discarded after the rebaseline. All software 
developed by TRW was also discarded. 

l. The importance of comprehensive reporting capability was recognized 
and provided for. As instrument and process performance became 
better understood, the system reporting capability also evolved so 
that now, detailed statistics on every key aspect of system 
performance can be routinely provided. 
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6.11.4 TEST 

a. The Importance of test data cannot be overemphasized. Time and 
effort in acquiring or constructing test data is well spent, the best 
test data being actual, acquired data. 

b. The use of a functional test philosophy, l.e., test plans and 
procedures structured to validate major functions, was a valid 
concept . 

c. There is a need to plan and develop a set of coordinated test data. 
The data is needed for testing during the various phases of 
implementation, integration, operation and maintenance. 

d. Easily accessible local simulators and files of test data sets should 
be available. This should be used for exercising local hardware and 
software systems realistically, especially with regard to data 
content and data rates. 

e. Integration is similar to implementation, but the test data should be 

more realistic and less specialized. The final stages of integration 

must include system testing with all the external interfaces. 

f. The development and use of comprehensive diagnostics and line tests 

to verify system integrity is invaluable when product quality cannot 
be accurately assessed until well after the fact, as is the case with 
MIPS and TIPS. 

g. Because of the extreme complexity of the TIPS special purpose 

hardware, numerous device diagnostics and built-in test capabilities 

were provided. With operational experience this capability has been 
improved and expanded to provide more meaningful process and device 
diagnostics. 

h. A Flight Segment simulator that will respond to commands and generate 
realistic telemetry test data is needed to allow the Flight Segment 
Controllers to "operate” the observatory. An effective, real-time 
simulation well before launch is desirable. This should include 
activation and normal orbital operations. In several instances, 
early in the program, commanding via GSTDN could not be completed 
during a pass. Since the Landsat Flight Segment was designed to be 
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"ssfs", no snosisliss could be attributed to the leek a/iam.of ^ 
simulations and rehearsals. It was annoying at times, however, when 
LOS occurred before the scheduled routine. 

i. Simulators and displays can be used to test maintenance of hardware 
and software systems. 

j. Unit testing of software fixes is not sufficient. Often, a new 
problem is introduced by the software "fix" that is not discovered 
until later in the data processing flow. 

k. Independent test teams working under an. organization separate from 
the software development organization provide an unbiased critique of 
the functionality of the software product as a byproduct of testing. 
However, a decision to use such teams must also consider the 
substantially increased costs and prolonged schedules. 

l. Early involvement of operations personnel in the testing of the 

system provides valuable feedback on the operability of the system, 
so that adjustments can be made prior to the operational timeframe. 

m. Although adequate inspection procedures were finally achieved in the 

CCT PROFILE program, for the non-video aspects of CCTs, video 
inspection was conspicuously absent. A presumption of acceptable 

video quality was made if the same image was satisfactory in the 241 
mm film and the P- or A-tape from which the CCT was produced. Since 
the CCTs were made from ingests different from those that produced 
the 241 mm film, the presumption of quality is therefore unreliable. 
This situation could be avoided by allowing the same ingest to 

produce both 241 mm film and CCTs. 

n. The independent test team concept for MIPS integration and testing 

resulted in lack of communication between system and software 
engineering groups. This Increased the I&T effort and made 
verification of requirements difficult. 

6.11.5 OPERATIONS 

a. The concept of "equivalencing” the amount of operations resources 

needed to service a special request to the number of products 
generated in the same timeframe permitted evaluating the "cost 
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effectiveness :: oi implementing the special request, giving each the 
priority deserved and even eliminating the least productive. 

b. Installation of parameter changes in a production support environment 
prior to population to operations significantly reduced the number of 
erroneous data values in operational parameter files. 

c. A need to modify some aspects of the TM R&D activity was dictated by 
operational experience and actual instrument and ground processing 
performance. The R&D period also pointed out several deficiencies in 
the TIPS design. As an example, the current design does not allow 
the implementation of scan level radiometric corrections. 

d. Operational experience has identified deficiencies in process control 
and data management, particularly in the area of error handling, that 
are continually being refined to improve the system's operational 
efficiency. 

6.11.6 QUALITY ASSURANCE 

a. It is believed that an unduly low priority was tacitly assigned to 
Quality Assurance, causing time loss by the backtracking that this 
made necessary. 

b. In addition, there was an underestimation of the time and resources 
needed to perform adequate Quality Assurance. As a result, 
troublesome problems arose with the external customer - the EROS Data 
Center, Sioux Falls, S.D., of the Department of the Interior. 
Considerable unforeseen time and effort were expended, to the 
detriment of production, in order to standardize the tolerances, 
measuring equipment and test techniques. For film processing 
problems it even became necessary to engage an external consulting 
contractor. 

c. No software was developed to permit ready cross-references among 
scene IDs, R-tape IDs, A-tape IDs, P-tape IDs, CCT IDs and film roll 
IDs. As a result, defect investigations required laborious alternate 
manual techniques resulting in substantial loss of man-hours. 

d. Inadequate physical facilities were provided for the orderly storage, 
retrieval and inspection of computer printouts and film rolls 
resulting in further lost time. 
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The Quality Assurance Group could have er^anr aH Hpfppf *fnvp#?t1 eationfi 
if an early display had been developed to show the history and 
statistics of all defects observed. 
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APPENDIX A 

BIBLIOGRAPHY OF LANDSAT GROUND SEGMENT PUBLICATIONS 

A. 1 SPECIFIC REFERENCES 

-1. PIR No. U-1T81-LSD-GS-73 

TIPS Performance Evaluation 
2 July 1984 

2. 1T81-LSD-SA&E-MEMO-344 

TIPS Image Processing Times Achieved During the August 1984 
Demonstration 

3. Documentation of the various tests is contained in the series of 
publications: 

LSD-XXX-TST-NNNN, where: 

XXX = Facility 

NNNN = Identification number 

4. PIR-U-1NA2-LSD-606 
Incidents of Severe Pixel Noise 
17 October 1983 by K. Rizk 

5. PIR-U-INA2-LS 4/5-648 

TAG Data for Forecasting Video Defects in 241 mm Film 
23 March 1984 by K. Rizk 


A. 2 GENERAL REFERENCES 


NO. 

TITLE 

FACILITY 

ISS/REV* 

DATE 

RESPONSIBLE 

SVS 9827 

Image Display Subsystem 

LAS 

0 

10/09/81 

W. Andiario 

SVS 9831 

28-Track High Density 
Tape Recorder 

LAS, IGF 

C 

2/15/83 

T. Aslam 

SVS 9832 

Laser Beam Recorder 
(LBR) 

TIPS 

J 

8/30/84 

R. Spencer 

SVS 9833 

Transportable Ground 
System (TGS) 

TGS 

A 

10/16/81 

P. Mellusi 

SVS 9834 

Federation of Functional 
Processors 

TIPS 

C 

3/7/83 

R. Spencer 


* See Legend. 
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NO, 

TITLE 

FACTT.TTY 

ISS/REV 

DATE 

RESPONSIBLE 

svs 

9837 

14-Track High Density 
Tape Recorder 

IGF 

B 

05/29/81 

T. As lam 

GES 

9838 

Control and Simulation 
Facility System 

CSF 

E 

10/30/81 

L. Kuykendall 

GES 

9839 

CSF Hardware 

CSF 

Reg. 

B(AN03) 

07/24/81 

K. Thom 

GES 

9840 

CSF Quick-Look Monitor 

CSF 

B(AN03) 

05/29/81 

K. Thom 

GES 

9841 

CSF Switching Unit 

CSF 

B 

11/13/80 

K . Thom 

GES 

9842 

TSIM Comp./CDHS I/F 
Unit Reqmt. Spec 

CSF 

Reg. 

C(AN06) 

10/02/81 

K. Thom 

GES 

9844 

Item Dev. Spec for FSS 
of LSD CSF 

CSF 

D 

12/18/81 

M. Elgin-Smith 

GES 

9845 

CSF Performance 
Evaluation S/S 

CSF 

C 

10/09/81 

N. Thurston 

GES 

9846 

CSF Test and Simulation 
S/S 

CSF 

C 

07/24/81 

R. Rhodes 

GES 

9847 

CSF Display Station 
Product 

CSF 

A 

02/18/81 

K. Thom 

SVS 

9929 

Flight Assurance Program GND 
Plan (Section 5) 

0 

09/15/78 

W. Berkey 

SVS 

9930 

Quality Requirements for 
LSD Ground Segment 
Subcontractors Plan 

GND 

0 

09/15/78 

W. Berkey 

SVS 

9931 

Configuration Management GND 
Plan 

A 

10/16/78 

B. Levin 

SVS 

9935 

Landsat-D Facilities 
Doc. (Bldg. 28, GSFC) 

CSF.MMF 

IGF 

D 

06/09/82 

W. Werner 

SVS 

9941 

Landsat-D Facilities 
Doc. (TGS) 

TGS 

A 

04/17/81 

P. Mellusi 

SVS 

9952 

42-Track High Density 
Tape Recorder 

DRRTS 

B 

10/30/81 

T. As lam 

GES 

10026 

Item Dev. Spec for GS 
Mgmt. S/S GMS 

MMF 

C 

12/23/81 

D. Abbott 
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NO. 

TTTT.F. 

FArTT.TTY 

TSS/REV 

DATE 

RESPONSIBLE 

GES 

10027 

MSS Image Processing 
System 

MIPS 

I(Reg. 

AN22) 

03/26/82 

J. Dietz 

GES 

10028 

* 

DRRTS 

DRRTS 

C(Reg. 

AN04-05) 

01/22/82 

T. As lam 

GES 

10029 

Landsat Assessment 
System and Subsystem 
Spec 

LAS 

B 

02/26/82 

R. Ho 

GES 

10031 

Parallel to Serial Data 
Output Device (PSDO) 
Added Vol. II & III 

LAS, MIPS, 

H 

9/5/84 

R. Ho 

GES 

10032 

Serial to Parallel Data 
Input Device (SPDI) 
7.27.80 Added Vol. II, 
III, IV 

LAS, MIPS, 
TIPS 

H 

07/27/82 

R. Ho 

GES 

10033 

Appendix A, HDT-AT DFCB 

GND 

E 

7/5/84 

A. Jai 

GES 

10034 

Appendix B, HDT-PT DFCB 

GND 

H 

8/30/84 

J. Kukla 

GES 

10036 

Data Base Mgmt (DAS) 
S/S 

MMF 

C 

09/04/81 

J. Ginnis 

GES 

10037 

Appendix F, GHIT-AT 
DFCB 

GND ER 

A 

9/5/84 

D. Abbott 

GES 

10038 

Request Support S/S 
(RSS) 

MMF 

C 

11/13/71 

R. Brown 

GES 

10039 

Item Development Spec 
for Flight Mgmt. S/S 
(FMS) 

MMF 

D 

10/09/81 

M. Elgin-Smith 

GES 

10040 

GS to NASA Tape Support 
Facility I CD 

GND 

A 

06/17/82 

T . Horn 

GES 

10044 

MSS Format Synchronizer 

IGF 

B 

07/24/81 

J. Dietz 

GES 

10045 

Ground Segment Spec 
(GSS) 

GND 

J 

07/18/83 

J. Brown 

GES 

10046 

Item Purchase Spec for 
MDA MSS Data Decommutator 

C 

07/31/81 


GES 

10047 

Comm. Control Proc. 

CSF 

D 

08/07/81 

R. Rhodes 
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GES 

10048 

CSF TLM Proc. 

CSF 

B 

08/21/81 

R. Rhodes 

GES 

10049 

CSF Command Proc. 

CSF 

D 

09/18/81 

J. Owen 

GES 

‘10050 

Control and Display 

CSF 

C 

09/11/81 

R. Rhodes 

GES 

10051 

Data Base & Flight 
Dynamics Files 
Description Doc. 

CSF 

0 

12/17/79 

R. Rhodes 

GES 

10052 

MSS 241 mm High 
Resolution Film 

IGF (04) 

B(Reg. 

AN03) 

10/09/81 

J. Dietz 

GES 

10055 

MSS 70 mm QA Film 
Format Doc. 

IGF 

A 

08/05/82 

J. Dietz 

GES 

10056 

Simulation Cont. Proc. 
(TSIM) 

CSF 

D 

02/20/81 

R. Rhodes 

GES 

10057 

0BC Support and Evalu- 
ation Proc. 

CSF 

D 

02/20/81 

R. Rhodes 

GES 

10058 

Flight Segment 
Simulation 

CSF 

C 

03/06/81 

R. Rhodes 

GES 

10059 

Nascom 1/0 Control 

CSF 

C 

07/17/81 

R. Rhodes 

GES 

10060 

IGF & LAS Matrix IGF, LAS 

Switches Vol. 2 & 3 added 

g 

09/05/84 

T. Aslam 

GES 

10061 

DRRTS Demultiplexer 

DRRTS 

A(AN02) 

09/11/81 

T. Aslam 

GES 

10062 

Item Development Spec 
for MMF-M 

MMF 

D(AN05 
& AN06) 

11/20/81 

04/09/82 

D. Abbott 

GES 

10064 

DRRTS TM Simulator 

DRRTS 

E 

09/5/84 

T. Aslam 

GES 

10066 

Goodyear High Resolu- 
tion Film Recorder to 
DMS I CD 

TIPS 

F 

06/22/83 

R. Spencer 

GES 

10070 

S/W Configuration 
Management Plan 

GND 

0 

11/10/80 

A. Westlake 

GES 

10071 

Geo. Err. Det S/W 

TIPS 

B(AN05) 

03/23/83 

06/30/83 

T. Keller 

GES 

10072 

MIPS S/W S/S 

MIPS 

0 

02/13/81 

R. Kaiser 
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NO. 

TTTTT? 

FACILITY 

IRR/RKV 

TUTF. 

RFRPONSTW.F. 

GES 

10073 

TIPS S/W S/S 

TIPS 

A 

11/16/82 

J. Kaiser 

GES 

10074 

• 

MMF-IGF (MIPS & DRRTS) 
ICD 

GND 

K-47, 

48 

11/02/82 

D. Abbott 

GES 

10075 

Appendix K, HDT-RM DFCB 

GND 

Reg. 

B(AN04) 

11/20/81 

A. Jai 

GES 

10076 

Appendix J, HDT-RT DFCB 

GND 

C 

01/29/82 

A. Jai 

LSD- 

201 

-I CD- 

NASA Document 



05/23/83 


GES 

10078 

TM 70 mm QA Film Format 
Doc 

GND 

C 

02/25/83 

R. Spencer 

GES 

10079 

Appendix I, 241 mm TM 
Film DFCB 

GND 

H 

06/22/83 

R. Spencer 

GES 

10080 

MSS CCT Format Doc 

MIPS 

B 

05/06/82 

R. Chu 

GES 

10081 

TM Image Process 
System Spec 

IGF 

F 

09/05/84 

R. Spencer 

GES 

10083 

C&DH S/S Simulator 

CSF 

B 

02/20/81 

K. Thom 

GES 

10084 

Downlink Sync Module 

IGF 

D 

08/30/84 

R. Spencer 

GES 

10085 

Timing S/S 

IGF 

B 

10/30/81 

T. As lam 

GES 

10086 

DRRTS/ CSF/TGS ICD 

GND 

A 

06/17/82 

R. Crouse 

GES 

10089 

Appendix E, GHIT-PT 
DFCB 

GND ER 

A 

09/05/84 

D. Abbott 

GES 

10090 

Appendix H, GFIT DFCB 

GND 

C 

01/15/82 

D. Abbott 

GES 

10091 

Ground Segment /NASA 
Project Office ICD 

GND 

0 

10/23/81 

T. Horn 

LSD- 

001 

■ICD- 

NASA Document 



05/23/83 


GES 

10093 

CSF/MMF-M ICD 

GND 

K 

12/14/82 

M. Elgin-Smith 

GES 

10094 

Ground Segment S/W 
Documentation Plan 

GND 

0 

08/23/82 

D. Miller 

GES 

10096 

Data Formatter 

TIPS 

B 

06/15/82 

R. Spencer 


Processor 
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NO. 

TITLE 

FACILITY 

ISS/REV 

DATE 

RESPONSIBLE 

GES 

10098 

TGS Software 

TGS 

A 

08/07/81 

R. Stiegler 

GES 

10099 

♦ 

Ground Segment Software 
QA Plan 

GND 

B 

06/24/82 

J. Szabo 

GES 

10102 

MMF-M H/W S/S Spec 

MMF 

A 

10/02/81 

K. Thom 

GES 

10103 

Operational QA Plan 

GND 



P. Kiss/ 
F. Rabat 

GES 

10105 

GS S/W Mgmt. Plan 

GND 

0 

08/18/82 

D. Miller 

GES 

10106 

Support Services Sub 
system (SSS) 

CSF 

A 

12/18/81 

N. Thurston 

GES 

10108 

Ground Segment Design 
Description Document 

GND 

A 

07/31/81 

M. Friedlander 

GES 

10109 

S/W Engineering 
Methodology 

GND 

0 

09/14/82 

S . Hannan 

GES 

10110 

Frequency Synthesizer 
Unit (FSU) 

IGF 

B 

10/30/81 

T. As lam 

GES 

10111 

Nascom I/F H/W 

CSF 

A 

02/27/81 

K. Thom 

GES 

10113 

Programming Practices 
Standards & Conventions 

GND 

0 

09/21/81 

D. Miller 

GES 

10114 

LSD Ground Segment 
Grounding 

GND 

C 

06/09/82 

G. Condon 

GES 

10115 

Ground Segment/NCC ICD 

GND 

C 

06/23/83 

B . Nims 

GES 

10116 

Network Control Center 

GND 

C 

05/06/82 

B . Nims 

SVS 

10122 

DFCB #1, Data Acq. Plan 

GND 

0 

08/28/81 

A. Kitto 

SVS 

10123 

DFCB #2, Telemetry 

GND 

0( AN-01- 
02) 

12/18/81 

A. Kitto 

SVS 

10124 

DFCB #3 , Command 

GND 

0 

09/25/81 

A. Kitto 

SVS 

10125 

DFCB #4, GPS 

GND 

0 

08/28/81 

A. Kitto 

SVS 

10126 

DFCB #5, Payload 

GND 

0(AN01) 

12/11/81 

A. Kitto 

SVS 

10127 

DFCB #6, Products 

GND 

0 

07/31/81 

F. Rabat 
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NO 

TITLE 

FACILITY 

ISS/PJJV 

DATE 

EES POMS ISLE 

GES 10134 

Ground Segment/NOAA ICD 

GND 

A 

11/20/81 

T. Horn 

GES 10135 
•+ 

Landsat— D Safety Design 
Plan 

GND 

0 

03/03/79 

P. Ruggles 

GES 10140 

Ground Segment /Orbit 
Comp Group (GS/OCG) ICD 

GND 

B 

06/21/82 

T. Horn 

GES 10142 

GS to Photo/Shipping 
Support ICD 

GND 

C 

07/26/82 

T. Horn 

GES 10143 

Ground Segment /Networks 
ICD 

GND 

A 

09/05/84 

T. Horn 

GES 10154 

Standard Peripheral I/F 
Vol. 2 added 

LAS, IGF 

C 

06/07/82 

L. Woolley 

SVS 10261 

Flight Segment to 
Ground Segment ICD 

FS/GS 



R. Clayton 

GES 10483 

241 mm High Resolution 
TM Film AT 

IGF 

A 

02/24/83 

H . Ahmed 

GES 10484 

MMF-TM 

MMF 

C 

09/05/84 

R. Brown 

GES 10485 

GS to Bldg. 23 (DIF) 
ICD 

GS 

0 

07/26/82 

T. Horn 

GES 10486 

MMF-M/MMF-T ICD 

MMF 

B 

02/15/83 

M. Elgin-Smith 

GES 10487 

Item Development Spec MMF 

for Interim TM Data System 

A 

09/15/83 

D. Abbott 

GES 10489 

MMF— T/TIPS ICD 

MMF, IGF 

L 

06/18/84 

E . Hogan 

GES 10490 

Appendix D (TM-CCT) 
Vol. VI, Products DFCB 


J 

05/08/84 


GES 10491 

Thematic Mapper Image 
Proc. Syst. Algorithm 
Control Book 


D 

03/26/84 

V. Karkhanis 
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LEGEND: 

0 « 

A, B = 

(AN) = 
-(C,D,L,M,T) 


Initial Issue 
Revision Number 
Alteration Notice 

Multiple Use Document Identification 
C = CSF 
D - DRRTS 
L = LAS 
M = MIPS 
T = TIPS 
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A 

A-Tape 

AC 

ACCA 

ACS 

ADP 

ADPE 

ADDS 

ADS 

AGC 

ANDP 

AOS 

AP 

APCS 

AROT 

ASCII 

AS IT 

ATTN 

BIL 

BIP 

BPI 

BSQ 

CALC 

CCA 

CCP 

CCT 

CCT-A 

CCT-AM 

CCT- AT 


ArFaNDIX 5 
ACRONYMS 


Additive 

HDT-A, radiometrically corrected, high density archival tape 

Alternating Current 

Automatic Cloud Cover Assessment 

Attitude Control System 

Automatic Data Processing 

Automatic Data Processing Equipment 

Applications Data Development System (Scrounge) 

Angular Displacement Sensor 
Automatic Gain Control 
Ancillary Data Calculation Process 
Acquisition of Signal 
Array Processor 

Accelerated Payload Correction Subsystem 
Acquisition Requirements Order Tape 
American Standard Code for Information Interchange 
Acquisition Status Information Tape 
Attention Processor (TIPS Software) 

Band Interleaved by Line 
Band Interleaved by Pixel 
Bits per Inch 
Band Sequential 

TAG Calculations 

Cloud Cover Assessment 

Cloud Cover Assessment Process 

Computer Compatible Tape 

CCT Containing Partially-Corrected Data 

Partially Processed CCT for MSS Data 

CCT Containing Partially-Corrected IM Sensor Data 
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CCT-PT 

C&DH 

COBOL 

COIL 

CODASYL 

Comtal 

CP 

CPC 

CPD 

CPL 

CPLB 

CPMS 

CPN 

CPU 

CRT 

CSF 


CCT CuuLaluiiig rulljr-COneCtcu Data 

CCT Containing Fully-Corrected TM Sensor Data 

Communication and Data Handling 

Common Business Oriented Language 

CSF Operator Interface Language 

Conference on Data Systems Language 

Trademark of Online Display Device 

Control Point 

Control Point Chip 

Control Point Directory 

Control Point Library 

Control Point Directory Build 

Cost Performance Measurement System 

Control Point Neighborhood 

Central Processing Unit 

Cathode Ray Tube 

Control and Simulation Facility 


DAS 

DBA 

DBSTAT 

DBMS 

DBMS-10 

DBMS-20 

DCL 

DDP 

DEC 

DECnet 

DFP 

DMA 

DML 

ms 

DRUB 

DRRTS 


Data Base Administration Subsystem 
Data Base Administrator 

Production Area Status Modification Utility 
Data Base Management System 

DEC— 10 System Software for Data Base Management 
DEC— 20 System Software for Data Base Management 
Digital Command Language 
Digital Data Processor 
Digital Equipment Corporation 

Digital Equipment Corporation Communications Network 

Data Formatter Processor 

Direct Memory Access 

Data Management Language (see GARDEN) 

Data Management System 

DEC Unibus DMA Interface Device 

Data Receive, Record and Transmit System 
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DSM 


DXFP 

Data Extraction and Formatting Process 

EDC 

EROS Data Center 

EROS 

Earth Resources Observation System 

ESR 

Equipment Service Report 

EWO 

Engineering Work Order 

FET 

Field Effect Transistor 

FFP 

Federation of Functional Processors 

FMS 

Flight Segment Management Subsystem 

FO 

Flight Operations 

FOS 

Flight Operations Subsystem 

FOV 

Field-of-View 

FPS 

Floating Point Systems Inc. 

FS 

Flight Segment 

FSS 

Flight Scheduling Subsystem 

FSW 

Flight Software 

F70-AM 

70 mm Latent Film of Partially Processed MSS Data 

F70-AT 

70 mm Latent Film of Archival TM Data 

F241-AM 

241 mm Latent Film of Partially Processed MSS Data 

F241-PM 

241 mm Latent Film of Fully Processed MSS Data 

F241-PT 

241 mm Latent Film of Fully Processed TM Data 

F241-AT 

241 mm Latent Film of Archival TM Data 

F/S 

Flight Segment 

GARDEN 

Data Manipulation Language 

GCDG 

Geodetic Correction Data Generation 

GCM 

Geometric Correction Matrix 

GCO 

Geometric Correction Operator 

GCP 

Geodetic Control Point 

GE 

General Electric Company 

GECP 

Geometric Correction Process 

GES 

Ground Electronic Specification 
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OFE 

GHIT 

GHIT-AM 

GHIT-AT 

GHIT-PT 

GMP 

GMS 

GPS 

GS 

G/T 

GSFC 

GSTDN 

GSIT 

HARVEST 

HCS 

HDDR 

HDDT 

HDT 

HDT-A 

HDT-AM 

HDT-AT 

HDT-PT 

HSI 

ICD 

IDT 

IFOV 

IGF 

IMS 

IMSFCC 

IPS 

IPSC 

2 

I RV 


nnuprnmont; FuT?li?h®d F.qij^Tunonfr 

Goddard HDT Inventory Tape 

Inventory Tape for Partially Processed MSS Data 
Inventory Tape for Partially Processed TM Data 
Inventory Tape for Fully Processed TM Data 
Geometric Correction Matrix Calculation Process 
Ground Segment Management Subsystem 
Global Positioning System 
Ground Segment 

Ratio of Gain to Systems Noise Temperature 
Goddard Space Flight Center 
Ground Spaceflight Tracking and Data Network 
Ground Segment Integrated Test 

Query Language 

HDDR Control Software 

High Density Digital Recorder 

High Density Digital Tape 

High Density Tape 

HDT-Archive Format (Partially Corrected) 

HDT-A for MSS Instrument Data 

HDT-A for TM Instrument Data, corrected radiometrically 
HDT for TM Instrument Data, fully corrected 
High Speed Interface 

Interface Control Document 
Industrial Data Terminal Corporation 
Instantaneous Field-of-View 
Image Generation Facility 
Information Management Subsystem 

Information Management Subsystem FFP Control Computer 
Image Processing System 
IPS Computer 
Inter-Range Vector Data 
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IQL Interactive Query Language 

Inter-Range Instrumentation Group Time Code 

IRIG-A IRIG Time Code Series A 

ITDS Interim TM Data System 

«# 


LAS 

LBP 

LBR 

LOS 

LNA 


Landsat-D Assessment System 
Library Build Process 
Laser Beam Recorder 
Loss of Signal 
Low Noise Amplifier 


M 

MAG 

MCCA 

MDKIO 

M&A 

MENU 

MIPS 

MIVT 

MNP 

MOR 

MPT 

MSCD 

MSS 


Multiplicative 

MSS Archival Product Generation 
Manual Cloud Cover Assessment 
MSS disk 

Multiplicative and Additive 
Control Processor, User Friendly 
MSS Image Processing System 
Major Item Verification Test 
Minor Frame 

Mission Operations Room 
Mission Planning Terminal 
Mirror Scan/Sweep Correction Data 
Multispectral Scanner 


NASA 

NASCOM 

NBTR 

NCC 

NCCS 

NIF 

NOAA 

NOCC 

NRZ 


National Aeronautics and Space Administration 

NASA Communications Network 

Narrow Band Tape Recorder 

Network Control Center 

Network Control Center Subsystem 

Nascom Interface Facility 

National Oceanic and Atmospheric Administration 
Network Operations Control Center 
Non-Return to Zero 
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WKZ.1 

NRZ-L 

NRZ-M 

NTTF 

OBC 

OCC 

ODP 

ORVT 

P-Tape 

PCL 

PCH 

PCD 

PCS 

PDF 

PDP 

PDR 

PE 

PEPG 

PES 

PGP 

PGS 

PLL 

PM/FL 

POCC 

PR 

PSDO 

QA 

QAF 

QFP 

QIO 

QLM 


Non-Eecurn to Zero Incrementing 
Non-Return to Zero Level 
Non-Return to Zero Mark 
Network Test and Training Facility 

Onboard Computer 

Operations Control Center 

Online Display Process 

Operational Readiness Verification Test 

HDT-P Fully Processed, High Density Tape 
Prime Compressed Low Mode 
Prime Compressed High Mode 
Payload Correction Data 
Payload Correction Subsystem 
Programmable Data Formatter 
Peripheral Data Product 
Problem/Defect Report 
Performance Evaluation 

Performance Evaluation Product Generation 
Performance Evaluation Subsystem 
Product Generation Process 
Product Generation Subsystem 
Prime, Linear, Low Modes 
Performance Monitor/Fault Location 
Payload Operations Control Center 
Process Request 

Parallel— to— Serial Data Output Device 

Quality Assurance 
Quality Assurance Film 

Quality Assurance Film Generation Process 
Queue Input/Output 
Quick-Look Monitor Unit 
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Rmax 

Maximum Radiance Value 

Rmin 

Minimum Radiance Value 

R-Tape 

(HDT-R) High Density Uncorrected Raw Tape 

RCFP 

Radiometric Correction Function Calculation Process 

R&D 

Research and Development 

RDCP 

Radiometric Corrected Process 

RDE 

Recursive Distortion Estimator 

RFP 

Request for Proposal 

RLUT 

Radiometric Look Up Tables 

RP06 

DEC 176 MB Disk or Removable Disk Storage Unit 

RP07 

DEC 283 MB Disk 

RQI 

Radiometric Quality Indicator 

RSS 

Request Support Subsystem 

RSX-11M 

Multi-Tasking Operating System Software 

SA 

Scientific Atlanta 

SC 

Signal Conditioning 

see 

Scene Content Correction 

SCD 

Systematic Correction Data 

SCROUNGE 

Applications Data Development System 

SCT 

System Control Terminal 

SEED 

Data Base 

SCDG 

Systematic Correction Data Generation 

SMB 

System Memory Bus 

SPDI 

Serial-to-Parallel Data Input Device 

SPI 

Special Peripheral Interface 

SPROUT 

Transaction Processor 

STC 

System Test Console 

STOL 

System Test and Operations Language 

STR 

System Test Review 

SU 

Switching Unit 
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xAC 

TAG 

TAS 

TCL 

TDQ 

TDRS 



VT78 

VT100 

WRS 


Telemetry and Gumma uu 

TM Archival Product Generation 

Tape Archives Subsystem 

TM Control Point Library Build Package 

TM Data Quality Assessment Package 

Tracking and Data Relay Satellite 

Tracking and Data Relay Satellite System 

Telemetry Extraction Process 

TM Final Product Generation 

Transportable Ground Station 

TM Initial Product Generation Package 

TM Image Processing System 

Thematic Mapper 

TM Archiving Subsystem 

TM Payload Correction System 

TM Quality Assurance Film Generation Package 

TRW Defense and Space Systems Group 

Test and Simulation Subsystem 

Virtual Address Extension DEC Model Computer 11/780 
Video Terminal 
Intelligent CRT Terminal 
Non-Intelligent CRT Terminal 

World Reference System, locating all scene centers 


i 
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